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In  this  thesis  the  effects  of  five  secondary  storage 
access  scheduling  policies  are  studied  in  the  context  of  a 
multiprogrammed  information  retrieval  system.   Such  systems 
are  characterized  by  independent  requests  for  groups  of 
records  from  the  disk  or  drum  secondary  storage  device. 
Further  processing  of  each  request  is  blocked  until  all 
records  of  the  group,  which  we  term  a  bulk,  are  accessed. 

A  model  which  captures  the  essential  behavior  of  the 
class  of  systems  under  study  is  described.   Important 
parameters  of  the  model  are  determined  from  a  study  of  an 
actual  system,  MEDLINE.   The  behavior  of  the  model  under  each 
of  the  five  scheduling  policies  is  studied  both  analytically 
and  via  simulation.   Results  show  unexpectedly  poor  performance 
by  the  commonly  used  SCAN  scheduling  policy.   Better  scheduling 
policies  are  defined  and  features  which  characterize  good  and 
bad  policies  are  enumerated.   Details  of  the  MEDLINE  study  and 
the  simulator  are  included  in  appendixes  along  with  an  atlas 
of  simulation  results. 


Ill 


Dedicated  to  my  wife  Palma 


IV 


ACKNOWLEDGEMENTS 

The  author  wishes  to  express  his  gratitude  to  his  thesis  and 
academic  adviser.  Professor  Jane  W.  S.  Liu,  for  her  guidance. 
My  former  academic  adviser,  Professor  C.  L.  Liu,  provided  much 
appreciated  wise  counselling  during  my  first  year  here.  The 
other  members  of  the  Committee,  Professors  David  J.  Kuck,  Duncan 
H.  Lawrie,  and  H.  George  Friedman,  contributed  to  making  my 
graduate  studies  a  valuable  learning  experience.  The  Department 
of  Computer  Science  and  the  National  Science  Foundation  provided 
financial  support  throughout. 

This  work  is  a  tribute  to  the  constant  support  and 
unfaltering  faith  of  my  wife,  Palma-  Without  her  efforts  this 
thesis  would  never  have  been  written. 


TABLE  OF  CONTENTS 

Chapter  Page 

1  INTRODUCTION   1 

2  THE  MODEL 4 

3  SIMULATION  STUDIES   2U 

t|  ANALYTICAL  STUDIES 76 

5       REVIEW,  CONCLUSIONS,  AND  SUGGESTIONS 108 

FOR  FUTURE  RESEARCH 

LIST  OF  REFERENCES 115 

APPENDIX  A  -  MEDLINE  STUDY 118 

APPENDIX  B  -  DISK/DRUM  SIMULATOR 149 

APPENDIX  C  -  ALGORITHM  COMPARISONS 162 

VITA 189 


VI 


LIST  OP  TABLES 


Table  Page 

3.1a  Request  Service  Time  for  2314  Type  Disk   ......  37 

3.1b  Balk  Service  Time  for  2314  Type  Disk  . 37 

3.1c  Core  Occupancy  for  2314  Type  Disk   .  . .37 

3.2a  Sample  Algorithm  Precedence  Matrix  for  Mean  of  .  .  .59 

Request  Service  Time 

3.2b  Sample  Algorithm  Precedence  Matrix  for  Mean  of  ...  60 

Bulk  Service  Time 

3.2c  Sample  Algorithm  Precedence  Matrix  for  Mean  of  .  .  .61 

Core  Usage 

3. 3a  Drum  Performance  Comparisons  as  a  Function  of  6   -  -  62 

3.3b  Disk  Performance  Comparisons  as  a  Punction  of  6   .  .  63 

3.4a  Drum  Performance  Comparisons  as  a  Punction  of  g   .  .  64 

3.4b  Disk  Performance  Comparisons  as  a  Punction  of  g   .  .  65 

3.5a  Drum  Performance  Comparisons  as  a  Function  of  i   .  .  66 

3.5b  Disk  Performance  Comparisons  as  a  Function  of  i   .  .  67 

4. 1  Differences  of  Random  Cylinder  Addresses  ......  93 

4.2  MSCAN  Latency  Approximation   ......97 

A.  1  MEDLINE  Tape  Format 120 

A. 2  MEDLINE  System  Statistics 123 

A. 3  MEDLINE  Oser  Statistics 123 

A. 4  MEDLINE  Query  Statistics  - 123 

A. 5  Term  Osage  in  Queries   .......  .......  .124 

A. 6  Percent  Usage  of  Terms  in  Queries   . 124 

A. 7  Connective  Usage  in  Queries   ...........  .124 

A. 8  Percent  Usage  of  Connectives  in  Queries   .....  .124 

A.  9  Term  Type  Usage  Distribution  ...........  .125 

A. 10  Connective  Type  Usage  Distribution  •  .......  .126 

B.  1  Data  Card  Formats .155 

B.2  COMMON  Data  Structures 156 


C. 1a  Drum  Performance 

C.1b  Disk  Performance 

C.  2a  Drum  Performance 

C. 2b  Disk  Performance 

C. 3a  Drum  Performance 

C.3b  Disk  Performance 


Comparisons 
Compacisons 
Comparisons 
Comparisons 
Comparisons 
Comparisons 


Summing  ever  i 
Summing  ever  i 
Summing  over  g 
Summing  over  g 
Summing  over  6 
Summing  ever  6 


163 
167 
171 
175 
179 
184 


Vll 


LIST  OF  FIGURES 
Figure  Page 

2. 1  Processing  of  a  Sample  Query  ......   6 

2.2  Stellhorn's  Machine   ................   9 

2.3  Hollaar  Based  Machine   .....  ...10 

2.4  Timeshared  Information  Retrieval  Machine  Model  ...  13 

2.5a  Service  Time  Line  for  FIFO,  MSCAN,  and  SBF  18 

2.5b  Service  Time  Line  for  SCAN  and  PSBF .18 

3.1  Simulator  Block  Diagram   ....... ...... .25 

3.2  Simulator  Summary  Printout  ............  .32 

3.3a  Request  Service  Time  for  SCAN   ...........34 

3.3b  Bulk  Service  Time  for  SCAN  .........  ....35 

3.3c  Core  Usage  for  SCAN .........36 

3.t*a  Rotational  Latency  for  FIFO  Drum  ..........40 

3.4b  Rotational  Latency  for  MSCAN  Drum   .........41 

3.4c  Rotational  Latency  for  SCAN  Drum  ..........42 

3.4d  Rotational  Latency  for  SBF  Drum  ..  ........43 

3.4e  Rotational  Latency  for  PSBF  Drum .44 

3.5a  Rotational  Latency  for  FIFO  Disk  ..........45 

3.5b  Rotational  Latency  for  MSCAN  Disk .46 

3.5c  Rotational  Latency  for  SCAN  Disk 47 

3.5d  Rotational  Latency  for  SBF  Disk   ..........48 

3.5e  Rotational  Latency  for  PSBF  Disk 49 

3.6a  Seek  Distance  for  FIFO  Disk   ...... ......  51 

3.6b  Seek  Distance  for  MSCAN  Disk 52 

3.6c  Seek  Distance  for  SCAN  Disk ..53 

3.6d  Seek  Distance  for  SBF  Disk  .............54 

3.6e  Seek  Distance  for  PSBF  Disk   ....  ....... .55 

3.7a  Bulk  Service  Time  for  Drum  with  g=20  ...  69 

3.7b  Request  Service  Time  for  Drum  with  g=20   ......  70 

3.7c  Core  Usage  for  Drum  with  g=20   ...  ........71 

3.8a  Bulk  Service  Time  for  Disk  with  g=20  ........72 

3.8b  Request  Service  Time  for  Disk  with  g=20   ......  73 

3.8c  Core  Usage  for  Disk  with  g  =  20 74 

4.1  A  Queueing  System   .........  ........77 

4.2a  Bulk  Service  Time  Lower  Bound  for  6=0.25  ......  86 

4.2b  Bulk  Service  Time  Lower  Bound  for  6=0.50  ......  87 

4.2c  Eulk  Service  Time  Lower  Bound  for  6=1.00  ......  88 

4. 2d  Bulk  Service  Time  Lower  Bound  for  6=2.00  ......  89 

5.1  Channel  Utilization  Potential  for  Druir  with  g=20  .  .112 

5.2  Channel  Utilization  Potential  for  Disk  with  g=20  .  .113 


VX11 


Figure  Page 

A-1  Logged  in  Users   .......  .....  .127 

A. 2  Search  Interar rival  Distribution  .........  .128 

A. 3  Search  Completion  Time  ..............  .129 

A.  4  Search  CPU  Time 130 

A.  5  System  Response  Time  .......  ......  ...131 

A. 6  Searches  Per  Session  ...............  .132 

A. 7  User  Response  Time  ........ ...... ...133 

A. 8  Terms  per  Search  Statement  ......  •••••••134 

A. 9  Basic  Terms  Per  Exploded  Term  ..........  .135 

A. 10  Single  Normal  Term  Postings   ...........  .136 

A. 11  Single  Exploded  Term  Postings   ..........  .137 

A. 12  Single  Search  Statement  Term  Postings   ......  .138 

A. 13  Search  Result  Sizes  Postings  ...........  .139 

A. 14  MEDLINE  Transaction  Tape  Sample 140 


Chapter  1 
INTRODUCTION 

Computer  systems  which  provide  information  retrieval 
services  are  not  a  recent  development  [ 1 ]•  Recently  however,  for 
economic  and  other  reasons,  there  has  been  a  trend  toward  the 
interactive  use  of  such  systems.  During  normal  operation  a 
number  of  users  may  attempt  to  retrieve  information.  The  number 
of  interactive  users  in  the  system  and  the  complexity  of  their 
requests  vary  with  time.  The  volume  of  data  reguired  and  the 
response  time  constraints  of  interactive  use  result  in  large  data 
bases.  Efficient  scheduling  of  accesses  to  the  rotational 
storage  devices  commonly  used  in  such  systems  becomes  a  critical 
concern  if  acceptable  performance  is  to  be  maintained  over  a  wide 
load  range. 

In  this  thesis  we  study  the  scheduling  of  rotational  storage 
devices  in  a  prototypical  interactive  inverted  file  information 
retrieval  system.  The  objective  is  to  obtain  a  qualitative  and 
quantitative  understanding  of  the  effects  of  scheduling 
algorithms  on  rotational  storage  performance,  buffer  memory 
requirements,  and  user  response  time.  Such  knowledge  would  be 
invaluable  in  designing  effective,  efficient,  balanced  systems  to 
provide  interactive  information  retrieval. 


In  Chapter  2,  the  terminology  used  in  this  thesis  is 
discussed.  k  model  of  the  rotational  storage  subsystem  is 
developed  and  contrasted  with  those  which  have  appeared  in  the 
literature.  System-vide  and  per-user  performance  measures  are 
defined.  Several  scheduling  algorithms,  selected  for  their 
popularity  or  perceived  performance  benefits,  are  defined.  To 
provide  realistic  operating  conditions  and  to  justify  assumptions 
of  the  model,  a  review  of  a  study  of  midline  operation  data  is 
made.  The  MEDLINE  study  itself  appears  as  Appendix  A  of  this 
thesis. 

In  Chapter  3  a  digital  simulation  study  of  the  model  is 
described.  Details  of  the  internal  workings  of  the  simulator 
appear  in  Appendix  B.  Ranges  of  simulation  input  parameters  are 
estimated  using  the  MEDLINE  data  as  a  guide.  Besults  of  1200 
simulations  which  cover  the  locus  of  operation  of  the  model  are 
summarized  in  tabular  and  graphical  form.  Complete  comparison 
tables  appear  in  Appendix  C.  The  performances  of  the  five 
scheduling  algorithms  studied  are  compared  with  respect  to  the 
parameters  of  the  model. 

The  behavior  of  the  model  under  each  of  the  five  scheduling 
algorithms  is  approached  analytically  in  Chapter  4.  All  five 
scheduling  algorithms  are  studied  in  terms  of  the  types  of 
reordering  of  gueued  reguests  that  they  produce.  Using  this 
approach  and  published  results,  we  produce  first  order  results, 
with  which  the  algorithms  can  be  compared  analytically.  These 
results  are  found  to  be  in  close  agreement  with  simulation  data. 


Chapter   5   summarizes    the    results   of    this   thesis. 
Suggestions  for  future  research  are  made. 


Chapter  2 
THE  HODBL 

In  this  chapter,  ve  describe  the  model  of  an  inverted  file 
system  used  in  this  thesis.  First ,  the  concepts  and  terminology 
of  an  inverted  file  information  retrieval  system  will  be 
introduced  to  provide  a  background  for  the  development  of  the 
model.  Data  from  an  operational  information  retrieval  system, 
NEDLINE,  is  introduced  to  justify  assumptions  of  the  model.  Five 
scheduling  algorithms  and  their  performance  measures  are  defined. 
The  complete  model  is  compared  and  contrasted  with  those  that 
have  appeared  in  the  literature. 

Inverted,  File  Information  Retrieval 

In  an  information  retrieval  system  a  document  is  a 
collection  of  text  vhich  may  be  an  article,  report,  book, 
abstract,  etc.  A  search  term  is  a  word  or  phrase,  with  or 
without  prefix  or  suffix  truncation  or  embedded  don't  care 
symbols,  by  vhich  documents  may  be  retrieved.  Relational 
operators  indicate  how  sets  of  documents  indexed  by  search  terms 
are  to  be  combined  to  produce  a  result  set.  Following  Boolean 
logic  and  set  theory,  two  common  operators  are  *  (and  or 
intersection)  and  ♦  (or.  or  union) .  The  and.  of  two  sets  of 
documents  produces  all  documents  that  are  in  both  sets.  The  or. 
of  two  sets  of  documents   produces  all  documents   that  are  in 


either  set.  A  third  operator,  commonly  denoted  as  -,  is  the 
relative  complement  or  and  not.  The  and  not  of  two  sets  produces 
all  documents  which  are  in  the  first  set  and  not  in  the  second. 
It  provides  a  more  natural  and  efficient  complete  set  of 
operators  than  set  complement.  A  query  is  merely  a  syntactically 
correct  combination  of  search  terms  and  relational  operators.  It 
produces  a  set  of  documents  vhich  match  the  search  terms  of  the 
query  in  the  manner  specified  by  the  relational  operators  of  the 
query. 

One  common  technique  used  in  the  implementation  of  this  type 
of  retrieval  system  is  file  inversion.  All  the  index  terms ,  the 
words  which  can  be  used  to  specify  a  document  and  the  'atoms' 
into  which  search  terms  can  be  split,  are  collected  in  an  index 
file.  Associated  with  each  index  term  in  the  index  file  is  a 
postings  list,  which  contains  a  pointer  to  each  document  indexed 
under  the  index  term.  To  retrieve  the  documents  corresponding  to 
a  query,  the  query  is  parsed,  index  terms  located  in  the  index 
file,  associated  postings  lists  located  and  then  combined  to 
produce  a  list  of  pointers  to  the  documents.  Figure  2. 1  shows 
how  a  sample  query  would  be  processed  using  an  inverted  file. 
Rules  of  the  query  language  specify  how  suffixing,  prefixing,  and 
don't-care  characters  in  search  terms  effect  their  mapping  into 
index  terms.  Inverted  file  organization  has  been  used  in  a 
number  of  well  known  systems  such  as  [26]. 


FIND  'dog'^cat' 


Index 
File 
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File 


IF 
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Processing   of   a  S»«pi«  Qusry 
Figure   2.1. 


The  inverted  file  organization  allows  as  to  avoid 
brute-force  scanning  of  the  collection  of  documents  but  does 
require  the  storage  of  potentially  large  postings  lists  which 
must  be  accessed  at  random.  Depending  on  the  number  of  index 
terms  and  the  level  of  inversion,  the  postings  lists  typically 
range  from  10*  to  100%  the  size  of  the  collection  of  documents 
indexed.  With  current  technology  the  only  feasible  storage 
device  which  provides  the  required  random  access  are  the 
rotational  magnetic  devices,  commonly  called  disks  and  drums. 
For  the  purposes  of  this  thesis  a  disk  is  considered  to  be  any 
rotating  device  which  may  require  physical  motion  of  the 
read/write  heads  to  access  a  record.  A  drum  is  any  rotating 
device  in  which  electronic  selection  and  rotation  are  all  that  is 
required  to  access  any  record.  is  examples,  the  IBS  2314  and 
33  30  disks  are  disks  and  the  Burroughs  B475  head-per-track  disk 
and  IBM  2305  drum  are  drums. 

By  storing  all  entries  of  each  postings  list  in  sorted  order 
the  computation  of  union,  intersection,  and  relative  complement 
can  be  performed  by  merging  postings  lists  and  casting  out 
approprate  entries  in  the  result.  For  example,  the  union 
requires  deleting  one  of  each  pair  of  duplicates  in  the  merged 
list  while  intersection  requires  deleting  all  but  one  of  each 
pair  of  duplicates.  It  was  observed  that  this  simple,  repetitive 
merging  task  is  often  inefficiently  performed  by  general  purpose 
computers  [6].  In  the  past  two  years  special  purpose  hardware 
which  quickly  and  efficiently  performed  some  or  all  of  the  work 
of  processing  a   query   has   been   designed   [4,5].    Stellhorn*s 
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machine.  Figure  2.2,  is  based  on  a  parallel  Batcher  merging 
network  followed  by  a  coordination  network  which  handled  the 
casting  out.  The  system  was  designed  so  that  postings  lists 
could  come  either  from  the  random  access  buffer  memory  or  a  fast 
head-per-t rack  disk.  Hollaar  demonstrated  the  design  of  a  small 
merge  processing  element  which  could  be  combined  into  merge  trees 
that  paralleled  the  logic  of  the  guery. 

For  the  purpose  of  our  discussion,  we  assume  the  inverted 
file  system  shown  schematically  in  Figure  2.3.  This  mechanism  is 
similar  to  Stellhorn's  but  based  on  a  tree  of  Hollaar  processing 
elements.  This  approach  reguires  that  all  postings  lists  be 
available  in  random  access  buffer  memory  because  of  the  data 
dependent  order  in  which  postings  list  entries  enter  the 
processing  elements  via  the  distributor.  Note  that  since  the 
postings  lists  are  always  accessed  in  the  sorted  order  they  are 
stored  in,  true  random  access  is  not  reguired.  It  is  sufficient 
to  be  able  to  serially  access  the  entries.  Banks  of  shift 
registers  are  a  possible  alternate  technology  for  the  buffer 
memory. 

llie  HEDLINE  Data 

To  model  an  interactive  inverted  file  information  retrieval 
system  realistically,  the  behavior  of  the  users  who  provide  the 
workload  must  be  understood.  This  section  provides  an  overview 
of  the  results  of  a  study  of  a  day's  traffic  file  from  MEDLINE. 
MEDLINE  is  an   online   version   of   NEDLAfiS   (HgDical   Literature 
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Analysis  and  Retrieval  System) ,  a  service  of  the  National  Library 
of  Medicine.  MEDLINE  currently  stores  citations  on  approximately 
one  half  million  articles  from  3,000  American  and  foreign  medical 
journals.  Citations  are  added  at  the  rate  of  75,000  monthly. 
Over  300  libraries,  hospitals,  and  medical  schools  use  the 
system.  The  complete  study,  including  details  of  the  data 
collection  and  possible  shortcomings  of  the  study,  comprise 
Appendix  A  of  this  thesis.  This  traffic  file  covers  the  19  hours 
of  operation  on  Monday,  January  13,  1975,  and  was  provided  by  Dr. 
Davis  McCarn  of  NLM. 

We  conclude  from  the  MEDLINE  data  that  the  distribution  of 
query  interarrival  times  is  approximately  Poisson  (Figure  A. 8  of 
Appendix  A).  This  fact  suggests  that  an  infinite  source  model, 
rather  than  a  more  complex,  state-dependent  finite  source  model, 
is  reasonable.  The  observed  distribution  of  index  terms  per 
query  (Figure  A. 2  of  Appendix  A) ,  even  after  correcting  for 
explodes  (Figure  A. 7  and  Table  A. 5  of  Appendix  A),  can  be  modeled 
as  a  geometric.  Explode  is  a  construct  particular  to  MBDLINE  but 
an  embodiment  of  a  concept  common  to  information  retrieval 
systems.  The  concept  is  that  a  single  term  can  be  elaborated 
into  many  terms.  In  various  systems  this  is  handled  with  macros, 
thesauri,  personal  dictionaries,  or  tree  structuring  of  the  index 
terms.  MEDLINE,  which  has  a  controlled  or  predetermined 
vocabulary  of  index  terms,  uses  a  tree  structure  to  reflect 
relationships  of  index  terms:  broader  than,  narrower  than, 
subsumed  under,  etc.  A  single  exploded  term  in  a  guery  would 
cause  the  retrieval  of  many  index  terms  and  their  postings  lists. 
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Data  collected  on  the  complexity  of  queries  and  sizes  of 
postings  lists  are  discussed  in  Chapter  3  with  respect  to  the 
estimation  of  simulation  parameters.  Other  results  from  the 
MEDLINE  study  will  be  mentioned  throughout  the  thesis  as  they  are 

needed- 

The  Model 

Figure  2.4  shows  schematically  the  model  of  a  timeshared 
information  retrieval  system  used  here.  A  query  is  modeled  as 
the  simultaneous  arrival  of  a  group  of  secondary  storage  access 
requests,  called  a  bulk.  These  requests  are  queued  in  a 
controller  which  selects  individual  requests  and  serves  them 
serially.  when  a  request  is  selected  for  service,  buffer  space 
sufficient  to  contain  the  postings  list  to  be  read  is  allocated 
in  buffer  memory.  Buffer  space  for  each  request  of  a  bulk  is 
held  until  all  requests  of  the  bulk  have  been  served.  At  that 
time  all  buffer  space  for  the  bulk  is  released.  This  corresponds 
to  the  operation  pattern  of  a  Hollaar  merger,  which  requires  all 
postings  be  core-resident  before  any  merging  begins. 

The  time  required  to  access  a  single  record  is  the  sum  of 
the  seek  time,  rotational  latency  time,  and  transfer  time;  ve 
call  it  the  request  service  time.  The  seek  tj.me  is  the  time 
required  to  position  the  read/write  heads  over  the  cylinder 
containing  the  desired  record.  For  this  work,  the  seek  time  is 
assumed  to  be  a  linear  function  of  the  seek  distance.  The  seek 
distance   is   the   positive   difference   of   successive   cylinder 
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addresses.  The  rotational  latency  is  the  delay  between  the 
completion  of  head  positioning  and  the  start  of  data  transfer. 
This  delay  is  due  to  the  rotational  nature  of  the  storage  device 
which  provides  only  periodic  access  to  any  location  on  the 
cylinder.  The  transfer  tj.me  is  the  time  required  to  read  the 
desired  record  from  the  device  into  the  buffer  memory.  Due  to 
the  periodic  nature  of  the  devices  it  is  possible  to  begin 
transfers  in  mid-record  and  later  pick  up  the  first  portion  of 
the  record.  This  trick  can  reduce  latency  in  cases  where  part  of 
the  latency  would  be  due  to  passing  over  the  end  of  a  record 
while  waiting  for  its  start.  It  is  not  considered  here;  all 
transfers  begin  with  the  start  of  a  record.  He  also  assume  that 
the  request  reguires  at  most  one  seek,  exactly  one  rotational 
latency,  and  exactly  one  transfer  time.  In  practice,  this  means 
each  record  exists  in  one  piece  on  one  or  more  tracks  of  a 
cylinder  for  a  disk. 

Clearly,  the  seek  time  depends  on  the  distance  from  the  last 
position  of  the  read/write  heads,  which  was  determined  by  the 
address  of  the  last  reguest  serviced.  The  starting  position  and 
record  size  of  the  last  reguest  serviced  also  combine  with  the 
seek  time  and  starting  position  of  the  current  reguest  to 
determine  the  rotational  latency  of  the  current  reguest.  Hence 
the  order  in  which  reguests  are  serviced  affects  the  reguest 
service  time.  Only  the  transfer  time  portion  of  each  reguest 
service  is  independent  of  the  state  of  the  device  or  order  of 
service  of  requests.  The  transfer  time  provides  a  lower  bound  on 
the  request  service  time   and   the   ratio   of   transfer   time   to 
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request   service   time   is   a   measure   of   the  efficiency  of  the 
request  service. 

The  followinq  assumptions  are  made  reqardinq  the  model  in 
the  remainder  of  the  thesis: 

1)  The  arrival  of  bulks  of  secondary  storaqe 
access  requests  is  a  Poisson  process  with  average 
arrival  rate  X- 

2)  The  number  of  secondary  storage  access 
requests  per  bulk  is  a  statistically  independent, 
identically  distributed  (IID)  qeometric  random 
variable  from  the  set  of  positive  integers  with 
expected  value  q. 

3)  Each  secondary  storaqe  access  request  has  an 
address  tuple  (c,r,l)  which,  along  with  the  bulk 
it  belonqs  to,  fully  characterizes  the  request. 
The  cylinder  number  c  is  a  random  variable  chosen 
uniformly  from  the  set  (1 ,2,3, ...n) ,  where  n  is 
the  number  of  cylinders  of  the  device.  The 
startinq  rotational  position  is  a  random  variable 
chosen  uniformly  on  the  interval  [0,1).  The 
record  length  1  is  a  random  variable  distributed 
exponentially  with  expected  value  6.  For 
different  requests,  c,  r,  and  1  are  statistically 
independent. 

U)  The  state   variables   C   and   E,  the   current 

position   of   the   read/write   head  in   terms  of 

cylinder    number    and    rotational  position, 

respectively,  fully  characterize  the  state  of  the 
device  at  any  time.    Auxiliary   state   variables 

may  be  introduced  in  each  scheduling  algorithm  to 
qualify  these  state  variables. 

The  distributions  for  bulk  arrivals,  bulk  size,  and  record 
lenqth  conform  to  those  observed  in  the  MEDLINE  study.  The 
distributions  assumed  for  cylinder  and  rotational  addresses  are 
based  on  the  use  of  an  unformatted  disk.  In  such  a  system  no 
attempt  is  made  to  distribute  postinqs  lists  on  the  device  by 
size,  frequency  of  access,  or  loqical  or  lexical  adjacency  in  the 
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index  terms.  It  is  conjectured  that  formatting  could  lead  to 
reduced  service  times  and  better  balanced  merges  [13,21].  The 
lack  of  data  on  logical  adjacency  or  access  freguency  and  the 
computational  complexity  of  even  sub-optimal  placement  procedures 
make  formatting  a  formidable  task  for  static  document 
collections.  In  a  dynamic  collection  such  as  HEDLINE,  the  cost 
of  constant  reformatting  could  well  be  prohibitive.  For  this 
reason,  no  veil  known  system  uses  formatted  devices. 

Measurements  and.  Performance  Metrj.cs 

To  evaluate  the  performance  of  the  five  scheduling 
algorithms  considered  here,  the  following  three  performance 
measures  have  been  selected: 

1)  The  bu.ik  service  time  is  defined  as  the  time 
from  the  arrival  of  the  bulk  to  the  completion  of 
service  of  all  the  requests  comprising  the  bulk. 

2)  The  reguest  servj.ce  tjjne  is  defined  as  the 
time  from  the  selection  of  a  reguest  for  service 
to  the  completion  of  data  transfer. 

3)  The  buffer  occupancy  is  the  time  weighted 
amount  of  buffer  space  in  use  by  all  bulks  in  the 
system  as  their  reguests  are  accumulated. 

Let  us  briefly  consider  the  implications  of  the  three 
measures  we  have  just  defined.  The  bulk  service  time  is  of 
central  concern  to  system  users,  as  it  largely  determines  the 
system  response  time  to  user  gueries.  The  request  service  time 
is  the  cost  to  the  system  to  service  one  member  of  a  bulk.  In 
non-bulk  arrival  systems  this  measure  is  commonly  minimized  to 
optimize  performance  from  the  viewpoint  of   the   system.    Buffer 
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occupancy  measures  the  cost  of  spreading  nrembers  of  a  bulk  in 
time  as  a  result  of  reordering  service  to  reduce  reguest  service 
time.  Since  buffer  memory  is  a  limited  system  resource,  the 
demands  that  a  scheduling  algorithm  places  in  terms  of  space  are 
important  to  the  system.  It  will  be  shown  that  some  algorithms 
trade  increased  buffer  usage  to  improve  bulk  and  reguest  service 
times  or,  conversely,  that  at  fixed  buffer  sizes,  algorithms  have 
differing  bulk  and  reguest  service  times.  Overlooking  the 
connection  between  buffer  usage  and  device  scheduling  proved  to 
be  the  cause  of  unexpectedly  poor  performance  in  Stellhorn,s 
multiuser  simulations  [  4 ]. 

Scheduling  Algorithms 

Scheduling  in  general  can  be  viewed  as  the  art  of  selecting 
a  permutation  of  the  work  on  hand  that  minimizes  some  cost 
function.  The  three  performance  measures  defined  above  can  all 
be  viewed  as  cost  functions,  to  be  minimized  individually  or 
jointly.  We  now  define  five  scheduling  algorithms  which  we 
compare  using  these  performance  measures. 

FIFO:  The  simplest  and  most  obvious  reordering  of  the 
requests  in  the  queue  is  in  fact  no  reordering  at  all.  Each  bulk 
is  served  in  the  order  it  arrived.  The  requests  in  each  bulk  are 
served  in  the  natural  order  they  appear  within  the  bulk.  Because 
of  the  assumptions  on  the  (c,r,l)  tuples,  this  is  equivalent  to 
service  in  random  order  within  bulks.  The  time  line  diagram  in 
Figure  2.5a  illustrates  the   behavior   of   one  bulk   under   FIFO 


request  service 
ben ins 


bulk  service 
beqins 


other  bulks 
in  service 


tine 


buffer 

space 

seized 


done 


Service   Time   Line    for   Firo,    HSCaM,   and   SBF 

Figure   2.5ft. 


18 


+  core 
usane 


requests  of 
other  bulks 
in  service 


+  core 
usane 


Service  Ti»e  Line  for  SCAM  and  PSBP 
Figure  2.5b. 


19 

service.  The  initial  delay  is  due  to  waiting  for  previous  balks 
to  complete  their  service.  Once  the  system  begins  to  service 
requests  in  this  bulk,  buffer  space  is  seized  as  each  request  of 
the  bulk  is  selected  (vertical  axis).  All  buffer  space  is 
released  when  the  last  record  transfer  is  complete. 

SCAN:  One  of  the  most  commonly  used  reorder inqs  is  produced 
by  ordering  all  outstanding  requests  by  cylinder  number  to  form  a 
cylinder  ordered  queue,  when  a  bulk  arrives  its  requests  are 
immediately  merged  into  the  cylinder  ordered  queue.  The 
read/write  head  sweeps  back  and  forth  over  the  cylinders, 
alternately  servinq  the  queue  in  ascending  and  descending 
cylinder  order.  The  direction  of  the  sweep  is  reversed  when  no 
requests  remain  beyond  the  read/write  head  in  the  current 
direction  of  travel.  This  approach  reduces  discrimination 
against  outside  cylinders  which  occurs  in  a 
shor test-seek- time- first  (SSTF)  scheduler  [15]  where  the  choice 
of  direction  is  a  function  of  distance  to  requests  in  each 
direction.  The  time  line  diagram  in  Figure  2.5b  illustrates  the 
service  of  a  single  bulk  under  the  SCAN  policy.  Notice  that 
because  the  policy  is  sensitive  only  to  the  cylinder  address  of  a 
request,  requests  of  a  qiven  bulk  will  generally  not  be  serviced 
consecutively.  Rather,  they  are  interleaved  with  requests  from 
other  bulks. 

MSCAN:  In  this  policy  each  bulk  is  serviced  in  the  order  it 
arrived,  as  in  FIFO,  but  requests  within  each  bulk  are  serviced 
as  in  SCAN.   Figure  2.5a  also  illustrates  the   behavior   of   this 
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policy  on  the  time  line  diagram.  The  direction  of  motion  of  the 
head  is  controlled  by  the  same  rule  as  in  SCAN  and  may  produce 
sub-optimal  seek  patterns  around  the  boundaries  between  requests 
of  different  bulks. 

SBF:  Once  the  reordering  of  requests  is  confined  to  single 
bulks  as  in  MSCAN,  attention  turns  to  the  reordering  of  whole 
bulks  with  respect  to  their  arrival  order.  Under  the  policy  of 
scheduling  the  shortest-bulk-first  (SBF) ,  shortest  is  determined 
by  the  number  of  requests  in  a  bulk,  with  ties  broken  by  the 
smallest  total  record  length.  Once  a  bulk  is  selected,  all  its 
requests  are  served  as  in  SCAN,  without  interruption.  The  time 
line  diagram  for  SBP  is  similar  to  Figure  2.5a. 

PSBF:  An  immediate  variation  on  SBF  is  to  allow  a  newly 
arrived  bulk  to  preempt  the  bulk  currenty  in  service  if  the  new 
bulk  is  shorter.  This  preemption  will  take  place  at  the  end  of 
the  request  service  cycle  in  progress  when  the  preempting  bulk 
arrived.  This  policy  allows  small  bulks  to  pass  larger  bulks 
while  the  later  are  in  service.  When  a  bulk  is  preempted  a 
transition  between  requests  of  differing  bulks  is  made  and  the 
head  travels  off  servicing  the  requests  of  the  second  bulk.  When 
the  service  for  the  second  bulk  is  completed,  the  head  moves  back 
to  the  neighborhood  where  it  was  when  the  preemption  occurred. 
This  generally  results  in  the  completion  of  the  remainder  of  the 
preempted  bulk  in  two  rather  than  one  segment.  The  time  line 
diagram  for  this  policy  resembles  Figure  2.5b. 
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To  this  point  the  question  of  the  scheduling  of  requests  on 
the  same  cylinder  has  been  ignored.  In  the  case  of  FIFO,  if 
successive  requests  happen  to  be  for  the  same  cylinder  they  are 
still  served  in  the  natural  order.  For  SCAN,  MSCAN,  SBF,  and 
PSBF,  if  two  or  more  requests  for  the  same  cylinder  are 
schedulable  (for  all  but  FIFO  and  SCAN  this  means  they  are 
members  of  the  same  bulk)*  they  are  scheduled 
shortest-latency-first  (SLF) .  Coffman  [ 16  ]  observed  that  seek 
scheduling  and  rotational  scheduling  are  independent.  It  has 
also  been  shown  [22]  that  SLF  is  nearly  optimal,  requiring  at 
most  one  extra  rotation  over  the  optimal  schedule.  Chile  optimal 
schedules  for  the  small  number  of  requests  likely  to  co-occur  on 
a  cylinder  are  not  hard  to  compute  [25],  SLF  is  used  throughout 
this  work  for  both  its  practical  and  analytic  simplicity. 

Simply  from  the  definitions  of  the  scheduling  policies  we 
can  make  some  guesses  as  to  their  relative  performance.  The 
reordering  in  SCAN  reduces  request  service  time  because  it 
reduces  seek  distance.  Its  net  effect  on  bulk  service  time  and 
buffer  occupancy  will  depend  on  the  net  effect  of  interleaving 
which  reduces  request  service  time  but  also  breaks  up  requests  of 
a  bulk,  which  in  turn  causes  the  effective  size  of  each  bulk  to 
increase.  To  improve  request  service  time  over  that  of  FIFO  but 
avoid  the  possible  disadvantaqes  of  bulk  interleaving  produced  by 
SCAN,  the  hybrid  policy  MSCAN  was  developed.  MSCAN  takes  a 
middle  approach,  reordering  only  within  the  bulks.  It  should 
improve  request  service  time  over  FIFO  but  avoid  excessive  bulk 
service  time  and  buffer  occupancy.   Using  SBF  we  expect  to  reduce 
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average  bulk  service  time  over  MSCAN.  It  is  veil  known  [33]  that 
if  order  of  service  does  not  effect  service  time,  then  shortest 
service  time  first  produces  mimimal  average  flow  time.  Notice 
that  we  make  no  attempt  to  consider  the  effect  of  reordering 
bulks  on  the  transition  between  the  last  request  of  one  bulk  and 
the  first  request  of  the  following  bulk.  He  also  know  that  the 
order  of  service  does  effect  service  time  in  our  case,  so  from 
[33]  we  can  only  conclude  that  SBF  should  be  better  than  FIPO 
(which  is  really  service  in  random  order  (SIRC)).  He  can  compare 
SBF  and  PSBF  by  noting  that  seek  distances  are  increased  and 
request  service  time  suffers  during  preemptions  which  occur  in 
PSBF. 

Literature 

There  is  a  vast  body  of  literature  on  both  disk/dram 
scheduling  and  the  larger  question  of  computer  system  simulation. 
The  current  work  is  patterned  after  the  pioneering  effort  of 
Scherr  [10]  in  the  modeling  and  analysis  of  CTSS.  A  good 
treatment  of  the  scheduling  problems  of  disks  and  drums  appears 
in  [16].  Several  papers  have  appeared  in  the  area  of  performance 
of  disks  and  drums,  including  [11,12,14,20,22].  Horks  which 
compare  various  scheduling  policies  include  [15,23].  The  most 
recent  analyses  of  disk  and  drum  performance  are  those  of  Fuller 
and  Baskett  [17]  and  Oney  [19].  Their  works  parallel,  for  the 
single  request  per  bulk  case,  the  analytical  development  in 
Chapter  4. 
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In  terms  of  the  current  problem,  the  major  deficiency  of 
work  to  date  is  that  all  bulks  were  of  size  one.  Attempting  to 
project  these  results  directly  to  the  more  general  case  results 
in  a  fallacy  of  composition.  Ihat  is  best  for  each  request 
individually  is  simply  not  best  for  requests  considered  as 
groups. 
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Chapter  3 
SIMULATION  STUDIES 

In  this  chapter  a  study  of  the  five  scheduling  algorithms  is 
made  using  a  digital  simulation  of  the  model.  An  overview  of  the 
simulator  is  provided,  with  details  deferred  to  Appendix  B. 
Ranges  of  input  parameters  of  the  simulation  are  estimated  using 
MEDLINE  data  as  a  guide.  Questions  of  convergence  and  stability 
of  the  simulation  are  discussed.  Samples  of  tabular  and 
graphical  results  are  presented.  Summary  results  of  the  1200 
cases  simulated  are  presented  and  guantitative  conclusions  on  the 
relative  performance  of  the  scheduling  algorithms  are  drawn. 

Sjmlulator  Overview 

The  model  described  in  Chapter  2  is  simulated  using  an 
event-driven  simulator  coded  in  FORTRAN  IV.  The  basic  structure 
of  the  simulator  is  shown  in  Pigure  3. 1.  It  consists  of  an 
event-list  management  package  and  a  group  of  event  routines.  The 
event- list  management  package  maintains  a  list  of  all  currently 
scheduled  future  events  as  (event, time)  pairs.  Events  are  added 
to  the  list  as  reguested  by  event  routines  and  removed  by  the 
management  package  when  time  advances  to  the  event.  In  a  basic 
cycle  the  management  routine  sets  the  time  to  that  of  the  event 
at  the  head  of  the  event-list  (advancing  time),  removes  the  event 
from  the  list,  and  calls  the  corresponding   event   routine.    The 
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event  routine  performs  some  computation,  possibly  altering  the 
queue  of  pending  access  requests,  and  calls  management  package 
subroutines  to  schedule  one  oc  more  nev  events.  It  then  returns 
to  the  management  package  vhich  repeats  the  cycle. 

The  queue  of  pending  access  requests  contains  all  the 
(c,r,l)  tuples  corresponding  to  pending  requests  in  addition  to  a 
system  of  links  which  maintain  per  bulk  information  and  provide 
all  the  information  necessary  to  schedule  the  requests  by  each  of 
the  five  algorithms.  Additional  tables  and  variables  maintain 
state  information,  record  performance  statistics,  and  collect 
distribution  information  on  input  values.  The  performance 
statistics  provide  the  desired  information  on  the  effects  of  the 
scheduling  algorithms  while  the  input  distribution  values  provide 
a  check  on  simulator  operation.  The  unit  of  time  is  one  rotation 
of  the  disk  or  drum  and  all  quantities  with  dimensions  of  time 
are  measured  in  this  unit. 

iD£lii  Parameters 

To  simulate  the  behavior  of  the  model  it  is  necessary  to 
supply  numerical  values  for  a  number  of  variables.  Three  of 
these  variables,  average  bulk  arrival  rate  A,  average  bulk  size 
q,  and  average  record  length  6,  specify  the  input  load 
characteristics-  The  characteristics  of  the  disk  or  drum  are 
specified  by  the  number  of  cylinders  (one  for  drums,  two  or  more 
for  disks)  and  the  two  coefficients  of  the  linear  seek  time 
function.    The   scheduling  algorithms  to  be  used  are  embedded  in 
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the  simulator  and  one  is  selected  for  a  given  run  by  an  input 
parameter.  The  amount  of  time  to  be  simulated,  the  number  of 
bulk  arrivals  to  be  simulated ,  and  the  number  of  independent 
samples  to  be  used  to  compute  confidence  levels  are  also 
parameters.  In  this  section  we  deal  in  turn  with  the 
determination  of  approprate  values  for  all  these  parameters. 

The  average  bulk  arrival  rate,  X,  the  average  bulk  size,  g, 
and  the  average  record  length,  6,  characterize  the  modeled  user 
load.  To  facilitate  comparison  of  results  for  varying  bulk  sizes 
a  secondary  variable,  i,  defined  as  Xg,  was  introduced.  Called 
the  arrival  intensity,  i  is  the  average  rate  at  which  access 
requests  arrive  in  the  system.  The  choices  of  values  for  X  and  g 
were  engineered  to  produce  only  a  small  number  of  values  of  i. 
This  allowed  the  comparison,  without  interpolation,  of  the  effect 
on  the  system  of  differing  bulk  sizes  at  constant  average  input 
load.  Using  the  analytical  expression  for  the  average  service 
time  for  a  FIFO  scheduled  request  the  disk  system  saturates  at  a 
value  of  i  of  approximately  . 32.  Short  test  simulations  for  the 
other  four  scheduling  algorithms,  in  which  values  of  X  and  g  were 
altered  to  produce  larger  values  of  i  until  the  system  saturated 
for  each  algorithm,  produced  an  upper  limit  at  about  i=.55.  To 
cover  a  fair  load  range  a  set  of  six  i  values  (.05,  .15,  .25, 
.35,  -45,  and  .55)  were  selected. 

Given  these  values  of  i,  knowing  either  g  or  X  would 
determine  the  other.  Since  data  on  the  number  of  index  terms  per 
query  was  available  and  since  this  distribution  is  independent  of 


28 

the  number  of  users,  g  vas  estimated  from  the  MEDLINE  data  and  X 
derived  from  the  defining  equation  of  i.  The  data  indicated 
small  searchs  were  very  common  (Figure  A. 6  of  Appendix  A)  •  In 
fact,  before  correcting  for  the  effect  of  explodes.  the  mean 
number  of  index  terms  per  query  vas  1. 92  with  a  standard 
deviation  of  0.99.  By  hand  count  the  average  number  of  postings 
lists  associated  with  an  exploded  term  was  3  0.25  with  a  standard 
deviation  of  50.97.  Using  statistics  on  the  frequency  of 
exploded  terms,  the  ad-justed  average  number  of  index  terms  and 
hence  postings  lists  per  guery  is  6.50.  While  these  numbers 
appear  small  they  are  in  general  agreement  with  observations  of 
EOREKA  users  [3,9].  To  hedge  against  the  possibility  that 
searches  are  small  because,  in  MEDLINE,  large  searches  are  very 
slow,  a  wide  range  of  values  of  g  was  selected.  The  values 
chosen  were  g= (2,5, 1 0,20,50) .  For  each  value  of  g  the  set  of  i 
values  and  the  relation  i=Xg  defined  a  set  of  X  values. 

The  initial  value  of  6,  0.50,  was  chosen  after  [17]. 
MEDLINE  results  provided  proof  that  the  distribution  was 
approximately  exponential  and  established  expected  values  in 
terms  of  number  of  postings  list  entries.  To  convert  from 
numbers  of  entries  to  fractions  of  a  rotation  it  would  be 
necessary  to  assume  entry  sizes  and  track  capacities.  Using 
numbers  typical  of  current  devices,  entries  per  rotation  range 
from  1500  to  about  9000.  MEDLINE  data  suggests  postings  lists 
average  601  entries  with  a  large  standard  deviation  of  1160.  An 
estimate  of  6  in  the  area  of  0.50  is  consistent  with  these 
measurements.   To  provide  a  margin  for  error  and   to   detect   any 
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differential  effect  of  record  length  on  algorithm  performance, 
four  values  of  6  were  used,  0-25,  0.50,  1.00  and  2.00.  The  value 
of  <$  =4.00  would  produce  a  case  where  transfer  time  dominated  the 
request  service  time.  As  discussed  earlier,  under  these 
conditions,  limiting  case  analytic  models  should  provide  accurate 
predictions.  Halving  the  lowest  value  of  6  would  only  reproduce 
the  behavior  of  the  0.25  case,  as  for  current  devices  the  seek 
and  latency  are  dominate  in  this  range. 

The  selection  of  the  number  of  cylinders  and  the  seek  time 
parameters  were  a  matter  of  discretion.  As  it  was  now  apparent 
that  the  number  of  cases  would  be  large,  only  one  disk  and  one 
drum  configuration  were  selected.  Since  the  model  admits  only 
one  possible  drum  configuration  there  is  no  loss  of  generality 
here.  However,  for  the  disk  there  are  three  parameters,  the 
number  of  cylinders,  incremental  seek  time  (time  to  move  one 
cylinder  once  the  arm  is  moving)  and  seek  start/stop  time.  For 
the  disk  simulated  these  three  parameters  were  chosen  to 
represent  a  2314-compatible  disk  with  maximum/minimum  seek  times 
of  75  and  10  msec. 

To  compare  the  five  algorithms  each  was  tested  for  all 
possible  combinations  of  parameters.  He  call  each  distinct  set 
of  parameter  values  (i,  g,  6,  device,  and  scheduling  algorithm)  a 
case.  Since  there  were  6  possible  values  of  i,  5  values  of  g,  4 
values  of  6,  2  device  configurations,  and  5  algorithms,  a  total 
of  1200  cases  had  to  be  simulated. 
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Since  the  amount  of  simulation  time  necessary  vas  clearly 
going  to  be  large,  a  careful  study  of  how  long,  in  terms  of 
simulated  time  and  bulk  arrivals,  each  simulation,  or  run,  vould 
require  and  how  many  times  each  case  needed  to  be  repeated  to 
provide  small  confidence  intervals  was  made.  The  length  of  the 
run  determines  how  completely  the  transient  effects  of  the 
simulation  startup  have  died  out  and  how  smooth  the  statistics 
gathered  will  be.  The  number  of  repeated  runs  determines  how 
small  an  estimate  of  the  uncertainty  of  the  results  can  be  made. 
Independent  but  otherwise  statistically  identical  runs  are 
produced  by  not  resetting  the  random  number  generator  between 
runs.  Tests  were  made  for  100,  250,  and  500  arrivals  per  run  and 
5,  10,  and  20  runs  per  case.  Using  the  FIPO  algorithm,  for  which 
exact  results  could  be  predicted,  simulation  output  was  analyzed. 
Based  on  the  cost,  which  was  proportional  to  the  number  of  bulks 
times  the  number  of  runs,  and  the  slow,  less  than  linear 
improvement  in  accuracy,  a  bulk  size  of  250  and  a  repetition 
factor  of  10  were  selected  as  the  best  affordable  combination. 
Using  this  combination,  time  required  was  estimated  to  be  27.9 
hours  on  the  CSO  360/75.  Due  to  early  termination  of  several 
runs  in  unstable  cases,  where  queues  outgrew  the  simulator's 
capacity,  the  actual  time  reguired  was  only  26.8  hours. 

Results 

The  amount  of  results  produced  defies  hand  analysis  in 
tabular  form.  Straight-forward  plotting  would  require  a  surface 
in  four-dimensional  space  for  each   combination   of   device   type 
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(2),  scheduling  algorithm  (5),  and  result  (3),  By  plotting  each 
result  as  a  function  of  arrival  intensity  foe  constant  record 
length,  device  type,  and  scheduling  algorithm  and  plotting  the 
result  curve  for  all  values  of  g  on  one  graph,  the  data  vas 
reduced  to  120  graphs,  each  with  five  curves*  Samples  of  tabular 
and  graphical  results  appear  in  Figures  3.2  and  3.3.  The 
vertical  bars  in  Figure  3.3  indicate  the  95*  confidence  level 
interval  for  all  data  points  for  which  two  or  more  runs,  out  of 
ten,  were  stable.  The  crosses  plotted  along  the  curves  indicate 
the  interpolated  estimate  of  the  utilization  or  traffic 
intensity,  the  ratio  of  total  busy  periods  over  total  simulated 
time,  of  the  device  for  values  of  0.2,  0.4,  0.6,  and  0.8.  It 
provides  an  indication  of  the  level  of  saturation  of  the  device 
for  the  given  conditions. 

The  results  of  a  qualitative  hand  reduction  of  the  graphical 
data  for  the  231 4  type  disk  and  5=0.25  appear  in  Tables  3.1a, 
3.1b,  and  3.1c.  The  six  arrival  intensities  were  reduced  to 
three  pairs,  with  0.05  and  0.15  being  low  arrival  intensity,  0.25 
and  0.35  being  medium,  and  0.45  and  0.55  being  high  arrival 
intensity.  The  algorithms  are  denoted  as  in  Chapter  2.  Brackets 
group  algorithms  which  were  judged  equivalent  in  terms  of  the 
result  being  tabulated.  Notice  that  in  Table  3.1a  SCAN  appears 
to  be  the  best  scheduling  algorithm  in  terms  of  request  service 
time  but  in  Table  3.1b  SCAN  is  one  of  the  poorer  algorithms  in 
terms  of  bulk  service  time.  In  Table  3.1c  SCAN  and  PSBF  are 
observed  to  do  worse  than  FIFO  in  terms  of  core  usage.  The 
effect  of  reordering  to  reduce   request  service   time  does  not 
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2314  Type  Disk  Results 


^ 


arrivarv  service 


fast 


slov 


low 

medium 

high 


[ MSCAN, SCAN, SBF, PSBF] 

SCAN       [MSCAN, SBF]      PSBF 

SCAN       [HSCAN, SBF]      PSBF 

Bequest  Service  Time 

for  2314  Type  Disk 

Table  3. 1a. 


FIFO 
FIFO 
FIFO 


arrival\ 

service 

fast 

slow 

low 

medium 

high 

PSBF 
PSBF 
PSBF 

[SBF, MSCAN] 
SBF      MSCAN 
SBF      SCAN 

SCAN 

SCAN 
HSCAN 

FIFO 
FIFO 
FIFO 

Bulk  Service  Time 
for  2314  Type  Disk 
Table  3.1b. 


^ 


arriva]\usage 


low 


high 


low 

medium 
high 


[SBF, HSCAN]  PSBF 
[SBF, MSCAN]  PSBF 
[SBF, MSCAN]     FIFO 


SCAN 
FIFO 
PSBF 


FIFO 
SCAN 
SCAN 


Core  Occupancy 
for  2314  Type  Disk 
Table  3.1c. 
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offset  the  increased  dispersion  of  requests  of  a  single  bulk 
under  these  conditions.  A  complete  tabulation  of  the  numerical 
results,  includinq  histograms  of  most  distributions,  runs  2400 
pages  plus  30  paqes  of  index.  Due  to  its  length  it  is  not 
reproduced  here. 

Comparing  Algorithms 

The  performance  of  disks  and  drums  depend  to  a  measurable 
degree  on  the  algorithm  used  to  schedule  the  service  requests  as 
well  as  on  other  parameters.  In  this  section  a  brief  review  of 
the  apparent  effects  of  the  parameters  on  performance  is  made. 

The  simulation  results  indicate  that  performance  at  constant 
arrival  intensity  improves  with  increasing  bulk  size.  At 
constant  arrival  intensity  bulk  service  time  grows  less  than 
linearly  with  bulk  size.  The  utilization  at  a  given  arrival  rate 
decreases  as  the  bulk  size  increases,  indicating  more  efficient 
handling  of  larger  bulks.  Bequest  service  times  decreased  with 
bulk  size  for  all  but  FIFO,  indicating  that  greater  freedom  in 
the  reordering  due  to  larger  bulks  was  beneficial.  Core 
occupancy  also  grows  less  than  linearly  with  bulk  size  except  for 
SCAN  and  FIFO. 

Bulk  service  time  grows  faster  than  linearly  for  all 
scheduling  algorithms  as  a  function  of  arrival  intensity.  This 
appears  to  be  due  to  the  buildup  of  queues,  as  request  service 
time  is  constant  for  all  but  the  SCAN  policy  as  a  function  of 
arrival  intensity.   Recalling   that   the   SCAN   policy   optimizes 
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seeks  over  all  available  requests  and  that  the  number  of 
available  requests  will  rise  as  arrival  intensity  increases,  we 
note  that  the  decrease  in  request  service  time  as  a  function  of 
arrival  intensity  for  the  SCAN  policy  is  not  surprising.  Core 
occupancy  grows  worse  than  linearly  for  the  SCAN  policy,  due  to 
the  increased  interleaving  of  bulks  as  we  speculated  in  Chapter 
2.  All  other  algorithms  exhibit  near-linear  core  occupancy 
growth  with  arrival  intensity. 

He  recall  that  varying  average  record  length,  6 ,  changes 
only  one  of  the  three  factors  in  the  service  time.  If  the 
average  record  length  is  small  its  contribution  to  the  overall 
service  time  will  be  slight  and  the  seek  and  latency 
characteristics  will  dominate  the  total  distribution. 
Conversely,  if  the  average  record  length  is  large  enough,  it  will 
swamp  the  effects  of  seek  and  latency.  For  the  FIFO  policy  the 
seek  time  and  latency  time  contribute  88%  of  the  request  service 
time  for  6=0.25.  For  average  record  lengths  of  0.25,  1.00,  and 
2.00  the  contributions  of  seek  time  and  latency  time  are  80%, 
6U%,  and  47%  respectively. 

The  rotational  latency  time  is  shown  in  Figures  3. 4a-3.4e 
and  3.5a-3.5e  for  drum  and  disk  respectively.  For  the  drum  case 
the  latency  is  a  function  only  of  g  for  all  but  the  SCAN  policy. 
Figure  3.4c.  This  is  due  to  the  fact  that  only  in  the  SCAN 
policy  is  the  service  of  bulks  interleaved  by  scheduling. 
Clearly  the  effect  of  the  interaction  between  requests  of 
different  bulks  will  increase  as  the  number  of   concurrent   bulks 
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grows  with  the  arrival  intensity.  The  value  of  g  has  the  very 
visible  effect  of  reducing  average  latency  as  g  increases.  This 
is  a  manifestation  of  the  increasing  freedom  of  choice  in  SLP 
scheduling  of  requests  of  each  bulk.  In  the  case  of  the  disk, 
the  average  latency  time  also  decreases  vith  increasing  average 
bulk  size  but  at  a  much  smaller  rate.  Since  SLF  scheduling, 
which  is  responsible  for  the  rotational  latency  behavior, 
requires  a  number  of  requests  per  cylinder  to  produce  improved 
latency,  the  cause  of  the  smaller  rate  of  decrease  is  clear.  In 
fact,  it  must  be  true  that  the  expected  value  of  the  number  of 
requests  per  cylinder  is  very  close  to  one.  For  example,  the  g=2 
curves  for  the  drum  lie  far  below  even  the  g=50  curves  for  the 
disk,  as  can  been  seen  by  comparing  Figures  3.  <*b-3.  Ue  with 
Figures  3. 5b-3.5e.  Figure  3.5c,  the  disk  under  SCAN,  shows  some 
decrease  in  latency  as  arrival  intensity  grows,  indicating 
increased  probability  that  multiple  requests  occur  for  single 
cylinders.  This  effect  is  due  to  the  increased  odds  of  more  than 
a  single  request  per  cylinder  brought  on  by  consideration  of  the 
requests  of  all  bulks  which  occurs  in  the  SCAN  policy.  The 
effect  is  correspondingly  diminished  over  the  drum  case,  for  the 
reason  just  given. 

Figures  ?.6a-3.6e  show  average  seek  distance  as  a  function 
of  arrival  intensity  and  bulk  size.  Seek  distance  rather  than 
time  was  selected  as  being  more  general,  since  seek  time  is  a 
function  of  technology  rather  than  geometry.  These  plots  are  for 
=i  disk  of  200  cylinders  but  they  can  be  scaled  up  or  down  for 
oLner    disks,   as   long   as   the   number   of   cylinders   remains 
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substantial  (more  than  20).  Seek  tine  can  be  computed  from 
distance  with  fair  accuracy  as  long  as  the  function  is  nearly 
linear  and  the  effect  of  the  zero  distance  seeks  can  be  estimated 
or  ignored.  Again,  in  all  but  the  FIFO  policy,  improvement  in 
average  seek  distance  is  observed  as  bulk  size  increases  at 
constant  arrival  intensity,  due  to  increased  scheduling  freedom. 
For  the  three  non- inter jec ting  policies,  FIFO,  MSCAN,  and  SBF, 
average  seek  distance  does  not  vary  with  arrival  intensity.  The 
SCAN  policy  shows  marked  reduction  in  average  seek  distance  as 
arrival  intensity  grows  while  for  the  PSBF  policy  only  a  slight 
increase  in  average  seek  distance  is  observed  for  small  bulks  at 
high  arrival  intensity.  This  odd  behavior  is  apparently  a  result 
of  "arm  stealing",  in  which  a  preempting  bulk  carries  the  arm  off 
to  some  distance  from  its  location  at  the  time  of  preemption 
while  servicing  its  needs. 

Both  the  seek  time  and  latency  time  are  quite  insensitive  to 
the  suppressed  variable,  6 ,  in  Figures  3.4,  3.5,  and  3.6.  Graphs 
for  the  other  values  of  6  (0.25,  1,  and  2)  are  only  minuscully 
different  from  those  shown. 

Simulation  Conclusions 

The  simulations  have  shown  that  the  choice  of  scheduling 
algorithm  does  affect  the  overall  performance  of  disk  and  drum 
systems.  To  compare  a  range  of  cases  we  make  point  by  point 
comparisons  and  weight  the  results  to  produce  an  overall 
comparison.   Except  in  the  rare  circumstance  where  one   algorithm 
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is   consistently   better  than  another  the  weights  ve  select  often 
determine  the  outcome. 

Tables  3.2a-3.5b  illustrate  one  approach  to  comparison  using 
equal  weights.  We  first  produce  the  precedence  matrices  shown  in 
Tables  3- 2a- 3- 2c.  For  each  measure  ve  compare  all  cases  for  all 
possible  pairs  of  scheduling  algorithms.  The  results  are  the 
table  entries,  where  >  means  that  the  algorithm  heading  the  row 
is  better  than  the  algorithm  heading  the  column.  A  <  means  the 
converse,  -  means  the  two  algorithms  are  equivalent  for  the 
performance  measure,  and  ?  means  no  comparison  could  be  made 
because  neither  algorithm  was  stable  under  the  conditions.  One 
algorithm  is  judged  better  than  another  with  respect  to  a 
performance  measure  if  the  mean  value  of  the  performance  measure 
for  the  first  algorithm  exceeds  the  mean  value  of  the  other 
algorithm's  performance  measure  by  more  than  the  maximum  of  the 
confidence  levels  of  the  measures.  If  the  difference  between  the 
means  is  less  than  the  maximum  of  the  confidence  levels  they  are 
judged  equivalent.  A  stable  algorithm  is  always  judged  better 
than  an  unstable  one. 

To  compare  over  a  range  of  cases  we  assign  points  to  the 
outcome  of  these  pair wise  comparisons  as  follows.  A  victory  (>) 
is  worth  2  points  to  the  victor,  a  tie  (=)  is  worth  1  point  to 
each  algorithm,  and  a  loss  (<)  is  worth  0  points  to  the  loser.  A 
?  is  not  counted,  as  are  the  other  three  possiblities,  in 
determining  points  or  number  of  comparisons.  Summing  scores  over 
a  number   of   cases   gives   an   equal-weighted   two   part   result 
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consisting  of  the  total  score  for  the  algorithm  and  the  number  of 
valid  comparisons  scored.  Tables  3.3a-3.5b  show  the  results  of 
such  comparisons  for  both  disk  and  drum  where  each  of  the  three 
pairs  of  6,  i,  and  g  where  summed  over.  In  Appendix  C  all  the 
possible  combinations  in  which  only  one  variable  was  summed  out 
are  given.  Por  example,  in  Table  3.3a  for  a  drum  with  6=1.00, 
summing  over  all  i  and  g  values  to  leave  the  scores  as  a  function 
of  only  6,  we  find  SBF  and  MSCAN  in  a  virtual  tie  with  185  and 
184  points  for  core  usage.  PSBF,  FIFO,  and  SCAB  follow  in  order. 
Looking  up  and  down  the  values  of  6  one  can  observe  how  it 
changes  the  comparison  of  the  algorithms  on  the  basis  of  core 
usage  results.  For  example  one  can  see  that  as  6  increases  FIFO 
improves  relative  to  SCAN  and  PSBF. 
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45 

79 

g=  * 

MSCAN 

91 

79 

MSCAN 

72 

79 

MSCAN 

125 

79 

i=.25 

SCAN 

160 

80 

SCAN 

70 

80 

SCAN 

22 

80 

SBF 

95 

80 

SBF 

110 

80 

SBF 

132 

80 

PSBF 

52 

80 

PSBF 

145 

80 

PSBF 

74 

80 

Disk 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=  * 

FIFO 

0 

61 

FIFO 

0 

61 

FIFO 

34 

61 

g=  * 

MSCAN 

74 

62 

MSCAN 

54 

62 

MSCAN 

105 

62 

i=.  35 

SCAN 

136 

68 

SCAN 

74 

68 

SCAN 

30 

68 

SBF 

69 

61 

SBF 

81 

61 

SBF 

97 

61 

PSBF 

35 

62 

PSBF 

105 

62 

PSBF 

48 

62 

Disk 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=  * 

FIFO 

0 

50 

FIFO 

0 

50 

FIFO 

11 

50 

g=  * 

MSCAN 

60 

50 

MSCAN 

40 

5C 

MSCAN 

83 

50 

i=.45 

SCAN 

112 

56 

SCAN 

63 

56 

SCAN 

35 

56 

SBF 

60 

50 

SBF 

73 

50 

SBF 

84 

50 

PSBF 

24 

50 

PSBF 

80 

50 

PSBF 

43 

50 

Disk 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=  * 

FIFO 

0 

36 

FIFO 

0 

36 

FIFO 

0 

36 

g=  * 

MSCAN 

45 

39 

MSCAN 

34 

39 

MSCAN 

62 

39 

i=.55 

SCAN 

96 

48 

SCAN 

64 

48 

SCAN 

48 

48 

SBF 

45 

39 

SBF 

58 

39 

SBF 

64 

39 

PSBF 

12 

36 

PSBF 

42 

36 

PSBF 

24 

36 

Disk  Performance  Comparisons  as  a  Function  of  i 

Table  3.5b. 
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Figures  3. 7a- 3. 8c  illustrate  the  relative  performance  of  the 
algorithms  Cor  g=20  and  6=0.50  for  both  the  drum  and  disk. 
Figure  3.7a  demonstrates  the  typical  ordering  of  the  algorithms 
in  terms  of  bulk  service  time.  Note  how  closely  bunched  all 
curves  but  the  one  for  FIFO  are.  For  the  droa  configuration  PSBF 
provides  the  best  bulk  service  time  while  SCAN,  due  to  bulk 
interleaving,  is  outperformed  by  MSCAN  and  SEF  in  addition  to 
PSBF.  Figure  3.7b  confirms  that  any  difference  in  bulk  service 
time  of  SCAN,  MSCAN,  SBF  and  PSBF  must  be  due  to  ordering  of 
reguests  and  not  the  individual  reguest  service  times,  which  are 
virtually  identical.  Figure  3.7c  clearly  illustrates  the  linear 
growth  of  core  usage  of  FIFO,  MSCAN  and  SBF.  Note  that  HSCAN  and 
SBF  produce  identical  core  usage  since  they  process  individual 
bulks  in  an  identical  manner.  PSBF  and  SCAN  show  greater  than 
linear  growth  in  core  usage  with  arrival  intensity.  SCAN  grows 
faster  than  PSBF  because  interleaving  is  common  under  SCAN  but 
occurs  only  during  preemptions  in  PSBF.  Notice  that  core  usage 
for  SCAN  actually  exceeds  that  of  FIFO  at  high  arrival 
intensities. 

Figures  3.8a-3.8c  demonstrate  the  relative  behavior  for  a 
disk  system  with  g=20  and  6=0.50  for  differing  scheduling 
policies.  As  in  the  drum  case  (Figure  3.7a)  all  but  FIFO  have 
closely  bunched  bulk  service  times.  PSBF  has  the  smallest  bulk 
service  time  while  SCAN  begins  to  outperform  MSCAN  at  large 
arrival  intensities  due  to  the  reduction  in  reguest  service  time 
overcoming  the  interleaving  effect  of  SCAN.  The  decrease  in 
request  service  time  for  SCAN  compared  to  HSCAN,  SBF,  and  PSBF  is 
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shown  in  Figure  3.8b.  Core  usage  in  Figure  3.8c  shovs  that  once 
more  SBF  and  HSCAN  have  identical  behavior.  SCAM  and  PSBF  again 
display  greater  than  linear  growth  with  arrival  intensity.  SCAR 
core  usage  exceeds  that  of  FIFO  for  larger  arrival  intensities. 
However  in  this  case  the  break  from  linear  growth  in  FIFO  core 
usage  is  due  to  system  saturation.  It  is  unfair  to  say  SCAN  is 
worse  than  FIFO  in  this  region  where  FIFO  is  unable  to  handle  the 
load. 


From  the  sample  curves  we  can  see  that  the  most  sensitive 
performance  measure,  core  usage,  varies  50%  between  the  best  and 
worst  algorithms,  excluding  FIFO,  for  drums.  For  disks  a  factor 
of  2.5  separates  SCAN  and  HSCAN  or  SBF  for  core  usage  at  the 
highest  arrival  intensity  simulated.  Differences  in  bulk  service 
time  for  the  four  reasonable  algorithms  (SCAN,  HSCAN,  SBF,  and 
PSBF)  amount  to  a  factor  of  2  for  disks  and  40%  for  drums.  In 
large  systems  differences  of  these  magnitudes  can  have 
spectacular  effects  on  overall  system  performance. 
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Chapter  4 
ANALYTICAL  STUDIES 

In  this  chapter  the  mean  and  variance  of  the  request  service 
time,  bulk  service  time,  and  core  occupancy  are  derived 
analytically  for  the  scheduling  algorithms  studied  in  this 
thesis.  Results  on  queue  length  and  90S  points  are  determined 
whenever  possible. 

Notation  and  Queueing  Theory 

Following  the  notation  in  Kleinrock  [32]  we  define  two 
generic  random  variables 

t  =  interarrival  time 
x  =  service  time 

Associated  with  each  of  these  random  variable  is  a  cumulative 
probability  distribution,  or  CDF,  of  the  form 

A(t)  =  Prob<t<t) 

B  (x)  =  Prob(x<x) 

and  the  corresponding  probability  density  function,   or   PDF,   of 
the  form 

a(t)  =  d*  (t)  /dt 

b(x)  =  dB(x)/dx 

Referring  to  Figure  4.1,  we  say   that   customers   arrive   at   the 
queue   with   interarrival  PDF  a(t).   When  the  server  becomes  free 
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it  selects  a  customer  from  the  queue  for  service  based  on  a 
gueueing  discipline.  The  length  of  time  required  for  server  to 
complete  service  of  the  selected  customer  is  called   the   service 

time  with  PDF  b(x)  . 

The  classes  of  queueing  systems  can  be  described  in  a 
notation  due  to  Kendall.  The  notation  K/B/l/Y/Z  defines  a 
queueing  system  vith  interarrival  distribution  A,  service  time 
distribution  B,  X  servers  working  in  parallel,  a  maximum  queue 
length  of  ¥  customers,  and  service  discipline  Z.  Symbols  for 
common  A  and  6  distributions  are  H  for  exponential  (Markov  or 
memory less) ,  D  for  deterministic,  and  G  for  general  (none  of  the 
above) .  If  maximum  queue  length  or  queue  discipline  are  omitted 
in  the  notation  they  are  assumed  to  be  infinite  and  FIFO, 
respectively.  He  employ  the  additional  notation  [C]  after  A  or  B 
to  indicate  bulk  arrival  or  bulk  service  vith  distribution  C.  In 
bulk  arrival  or  bulk  service  the  customers  arrive  or  are  served 
in  groups,  of  possibly  varying  sizes,  rather  than  individually. 
For  example,  an  H[tt]/G/1  queue  has  exponentially  distributed 
arrivals  of  bulks  of  customers.  Each  bulk  in  this  case  contains 
exactly  4  customers.  Each  customer  is  served  individually  by  the 
single  server  in  order  of  arrival  (FIFO).  The  distribution  of 
service  time  is  general  (any  valid  PDF).  In  this  chapter  ve  will 
make  use  of  the  notion  of  syper  customers  to  aid  our  analyses.  A 
super  customer  is  really  a  group  of  customers  taken  as  a  group 
but  treatad  as  one  larger  customer  by  the  queueing  system.  In 
this  regard  ve  will  speak  of  the  service  time  of  a  super  customer 
as  the  service  time  in  the  queueing  sense. 
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An  important  assumption  which  underlies  almost  all  the 
results  of  queueing  theory  is  independence  in  both  the  arrival 
and  service  processes.  The  independence  assumption  assures  that 
the  arrival  or  service  time  of  one  customer  does  not  alter  the 
arrival  or  service  time  distribution  of  any  other  customer.  Put 
another  vay#  knowing  the  complete  past  history  of  the  gueueing 
system  does  not  change  the  predictions  of  the  next  arrival  time 
or  service  time  from  that  of  the  arrival  or  service  PDF.  In 
cases  where  independence  is  not  assured  the  results  can  only  be 
viewed  as  approximations. 

Important  performance  variables  for  gueueing  systems  include 

N(t)  =  number  of  customers  in  the  queue  at  time  t 

w  (n)  -  waiting  time  (in  queue)  for  the  nth  customer 

T (n)  *  system  time  (gueue  plus  service)  for  the  nth 
customer 

We  shall  consider  only  cases  where  the  gueueing  system  has 
reached  a  steady  state.  In  this  case  we  can  drop  the  t  or  n  and 
consider  mean  values  N,  H,  and  T  of  N  (t)  ,  I  (n) ,  and  T  (n) , 
respectively.  Recalling  that  x*  was  the  mean  service  time,  we  see 
that 

T  =  x  ♦  W 

If  we  define  X  to  be  the  average  arrival  rate  of  customers,  the 
utilization  factor  is 

p=  Xx" 

For  stable  systems  0<p<1  (<1  for  D/D/1) ;  the  average  rate  at 
which   work   arrives   must  be  less  than  the  average  rate  at  which 
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work  is  completed-  For  p>1  the  work  piles  up  faster  than  it  can 
be  handled  and  the  queue  grows  without  bound. 

An  important  result  relating  N  and  T  in  stable  systems  (p<1) 
is  Little* s  result 

N  =  XT 

This  result  requires  no  assumptions  on  the  nature  of  a(t)  or  b(x) 
and   can   be  applied  to  different  portions  of  the  queueing  system 
if  proper  definitions  for  N,  X,  and  T  are  observed. 

The  one-sided  Laplace  transform  of  f(t),  denoted 

oo      -st 
F*(s)  =  /  f(t)e    dt 
0 

will  be  required  in  some  of  our  work.  The  z-transform  of  a 
function  g (x) ,  where  x  is  drawn  from  the  non-negative  integers, 
will  also  appear  occassionally  and  is  defined  as 

00 

G(z)  =  I   g(x)z 
x=0 

Hsvie*  2l  Assumptions 

As  discussed  in  Chapter  2,  we  assume  that  the  arrival  of 
bulks  of  secondary  storage  access  requests  is  a  Poisson  process 
with  average  arrival  rate  X-  Following  the  convention  that  the 
probability  density  function  (PDF)  of  a  continuous  random 
variable  is  denoted  by  a  lower  case  letter  and  its  associated 
cumulative  distribution  function  (CDF)  by  the  corresponding  upper 
case  letter,  for  the  arrival  process,  we  have 
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-Xt 
a(t)  =  Xe  t  >  0  (PDF)  (4.1a) 

-Xt 
A(t)  -  1-e  t  >  0  (CDP)  (4.1b) 

The  expected  value  of  a  random  variable  x  is  represented  as  B[ x ] 

2  2      2 

or   x.    The  variance  of  x,   a  ,  can  be  computed  as  E[ x  ]-E[  x  ]  .. 

x 

For  our  arrival  distribution,  letting  t  be  the  interarrival  time 

of  the  bulks 

E[t]  -  1/X  (4.2a) 

2      2 
a  =  1/X   or   a  =  1/X  (4.2b) 

t  t 


The  number  of  secondary  storage  access  requests,  k,  in  a 
bulk  is  assumed  to  be  geometrically  distributed  with  expected 
value  g.   It  is  easy  to  show  that 


k 

g     =   Prob(bulk  contains   k  members)    *  _J_    fStzJJ    (4.3a) 


5^  \\) 


E[kJ  -  g  (4.3b) 

2 
c  =  (g-1)g  (4.3c) 

k 


Requests  are  assumed  to  be  uniformly  distributed  over  the  device. 
Hence  for  the  cylinder  addresses  of  a  device  with  n  cylinders 

Prob (request  lies  on  cylinder  i)  =  1/n     i=1,2,3...,n 

The  rotational  position,  8 ,  of  the  start  of  each  request  is 
assumed  to  be  uniform  over  the  rotational  period  of  the  device, 
so  that 

r  (0)  =  1  0  <  9  <  1    (4.4a) 


82 
P(6)  =  e  (4.4b) 

The  record  length,  x,  is  assumed  to  be  exponentially   distributed 

with  mean 

-x/6 
l(x)  =  e  x  >  0        C».5a) 

6 

-x/6 
L(x)  =  1-e  (4.5b) 

2     2 
o     =    6      or  o     =    6  (*»-5c) 

X  X 

The  final  major  assumption  is  that  the  seek  time  of  the  disk 

is   a   linear   function  of   the   distance  travelled  for  non-zero 

distances.   Hence  we  have 

t  (d)  =  0  if  d=0       (4.6) 

s 

=  \\>   d+ij;  if  d=1,2,3...  n-1 

1    0 

The  request  service  time,  t  ,  is  defined  as  the  sum  of   the 

r 

transfer   time,  t  ,  the  rotational  latency  tiwe,  t  ,  and  the  seek 

time,  t  ,  or 
s 

t   ■  t  ♦  t  ♦  t  (4.7) 

r    t   1   s 

The  bulk  service  time  is  more  correctly  the  bulk  system  time; 
the  total  queueing  and  service  delay  experienced  by  a  bulk-  If 
we  define 

w  =  nin(i  ,w  ,w  ,...,w  )  (4.8a) 

f        12   3      n 

W   =  max(W  ,W  ,w  , ,tf  )  (4.8b) 

1         12   3       n 
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where  W.  is  the  gueueing  time  of  the  i    member  of  the  bulk,  then 
obviously  we  can  define  the  bulk  service  time,  T,  as 

T  =  t  ♦  W  (4.9) 


If  we  define 

t   -  time  at  which  request  i  of  bulk  j  begins  service 
ij 

x       =  service  time  of  request  i  of  bulk  j 
ij 

1   =  buffer  space  used  by  ceguest  i  of  bulk  j 
ij 

n  ■  number  of  requests  in  bulk  j 
j 


then  we  can  define  the  mean  buffer  occupancy,  or  core  usage,  as 

n 

C  =  lim    I        I      1   (t    *x    -t   ) 
„->•   -j=1  i=s1   ±j   n  j   n  j   ij 

j 1 

t   +x 
n  w   n  w 
w    w 

This  is  the  amount  of  buffer  space  used  times  the  time  it   is  in 
use  divided  by  the  total  elapsed  time. 

l2HQ^s  on  Performance  of  Drum  and  Disk  Systems 

He  note  again,  Eq.  (4.7)  ,  that  there  are  three  components 
of  the  reguest  service  time:  seek  time,  rotational  latency,  and 
transfer  time.  The  seek  time  and  rotational  latency  are  overhead 
in  the  access  times  of  the  disk  and  drum  systems  under 
consideration.   Clearly,  to  minimize  reguest  service  time  we 
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should  strive  to  reduce  or  eliminate  seek  and  rotation  time.  In 
the  limiting  case  request  service  time  consists  of  only  the 
Poisson  distributed  transfer  time.  Hence  transfer  time 
represents  a  lower  bound  on  the  request  service  time.  In  this 
case  the  model  of  the  storage  system  simplifies  from  an  H/G/1 
system  to  M[x]/H/1  in  Kendall's  notation. 

Let  p   be  the  probability  that  the  systenr   has   k   customers 

and   y  be  the  mean  service  rate.   By  inspection,  the  steady  state 

Chapman- Kolmogorov  equations  for  the  system  are 

k-1 
0  =  -(X*y)p  *pp    *X  I   p  q         k>1  (4.  11a) 

k   k+1    i=0  i  k-i 

=  -Xp   ♦  yp  (4.11b) 

0      1 

Using  z-transforms  we  may  convert  the  last  set  of  equations  to 
the  equivalent  form 

0  =  -XP(z)-y[P(z)-p  ]*y[P(z)-p  ]/z*XG(z)P(z)    (4.12) 

0  0 

Solving    for   P(z)    we   have 

P(z)    =  yp0(1-z)      (4.13) 

y(1-z)-Xz(1-G(z)) 

p      ■    1-p   and       p=      B[x]/y  (4-14) 

0 

G  (z)    =    z(1-ct)  (4.15) 

1-az 

where     a-    (g-1)/g   and   E[  x  ]  ■   G«(1)     ■  9 

To  find  the  average  queue  length  we  evaluate  P* (1)  and  obtain 

2 
L   =  P*  (1)  =   X6q    =  g.Q (4.16) 

q  1-X6g      1-p 
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For  the  special  case  of  g*1  we  get  the  B/H/1  result  as  expected 
(observe  that   o£*0,  all  bulks  are  of  siie  one  in  this  case). 

The  bulk  service  time,  T,  which  is  simply  the  average 
request  service  time  times  the  sum  of  the  average  number  of 
requests  in  the  queue  and  the  average  bulk  site 

T  =  6(1   *g)  (U. 17a) 

g 

~    q<S  (4,17b) 

1-Xg6 

=   q6  (U.17c) 

1-i6 

The  value  of  T  given  by  this  equation  is  a  lower  bound  to  the 
average  bulk  service  time.  Figures  4. 2a-4. 2d  shot  the  behavior 
as  a  function  of  arrival  intensity,  i,  and  average  bulk  size,  g, 
for  average  record  length,  5,  of  0.25,  0.50,  1.00,  and  2.00  on 
the  same  scales  as  for  Figure  3.3b.  The  average  request  service 
time,  S,  is  trivially  the  same  as  the  average  transfer  time 

S  =  1/p  =  6  (4.18) 

The  buffer  memory  usage  is  just  n* (n-1) ♦  (n-2) ♦. •  •♦I  blocks  of 
size  (txme*length)  6  -   Hence 

1*2*3+. ..*n  *  n(n*1)/2  (4.19) 

The  mean  buffer  space  usage,  C,  is  then 

2    oo 

C  -  X6    I   g   k(k*1)/2 
k=1  k 


2   oo        ,   vk-1 

=  X6 


.       k- 1 
I     JL     3Z1\       Mk*1) 
=1   2g  ^  g  / 
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2  2        2 
A6  q  =  X6t  g  (U. 20) 

r 


Z1ZQ.   Analysis 

He  are  now  ready  to  begin  our  analysis  of  scheduling 
policies-  The  analysis  of  the  FIFO  algorithm,  first  for  the  drum 
and  then  for  the  disk,  provides  an  example  of  the  general  method 
of  attack-  The  components  of  the  reguest  service  time,  that  is 
seek  time  (disk  only)  ,  rotational  latency  time,  and  transfer 
time,  are  determined  and  combined.  Using  the  service  policy  and 
request  service  time,  the  core  occupancy  is  computed-  Then, 
whenever  possible,  request  service  times  are  combined  using  bulk 
size  distributions  to  produce  super-custoners  in  an  M/G/1 
queueing  model.  With  the  bulk  arrival  distribution  the  bulk 
service  time  can  be  determined,  along  with  queue  length  in 
requests  and  average  bulks- 

FIFO  Policy,  for  Drum  System 

Since  FIFO  does  not  disturb  the  natural  order  of  the  bulks 
or  the  requests  they  contain,  the  expected  value  and  variance  of 
the  latency  time  are  given  by 

t   =  1/2  (4.21a) 

1 

2 
a   =  1/12  (4.21b) 

1 

The  request  service  time   is   just   the   sum   of   the   rotational 
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latency  and  the  transfer  tine,   since,  by  our  undisturbed  initial 

assumptions,   these   random   variables    are    statistically 

independent,  we  have 

t  »  t   ♦  t  *  5  ♦  1/2  (4.22a) 

r    t    1 


2    2    2    2 

a^o+o^S*    1/12 
r    t    1 


(4.22b) 


Recalling  that  x  is  the  random  variable  representing  the  service 
time   distribution   and   that,    in  FIFO,   all  requests  are 


statistically  independent,  ve  can  immediately  say 

x  =  gt  ■  g  (6*1/2) 

r 


(4.23a) 


2     2     2  2      2  2 

a     -  ga  *(t  )  a  «  g(5  *1/12)  ♦  (6*1/2)  (g-1)g    (4.23b) 
x     r   r   g 


where  ve  have  chosen  the  service  time  to  be  that  of  a  whole  bulk. 
The  traffic  intensity  is 

p  =  Xx  =  Xg(6*1/2)  (4.24) 


With  the  mean  and  variance  of  service  time  as  defined  for  the 
M/(3/1   queueing  system  ve  can  apply  the  Pollaczek-Khinchin  mean 

value  formula 


T  = 


2   2 
X  ( a  ♦  x  ) 

1  ♦  __* 

2x(1-p) 


(4.25) 


After  substitution  of  our  equations  for  the  terms  of  Eq.    (4.25) 
ve  arrive  at  the  following  expression  for  the  bulk  service  time 


T  =  1  ♦  X(6  +izi2»(?q-i)  <fi*V2)..M  9(6* 
L     2(6*1/2)  (1-Xg(6*1/2)) 


1/2)    (4.26) 
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solely  in  terms  of  the  three  parameters,  A,  6,  and  g.  The   core 

usage   can   be   immediately  determined  using  the  same  argument  as 

the  lower  bound  analysis,  by  substituting   6*1/2   for  6   as   the 

request  service  time  we  find 

2 
C  *  X6 (6*1/2) g  (4.27) 


FIFO  Policy,  for  Disk  Systeir 

The  disk  case  parallels  the  drum   solution   just   presented. 

However,  for  the  disk  we  must  additionally  determine  the  mean  and 

variance  of  the  seek  time,  which   are   required   to  compute   the 

request  service  time.   Recall  that  in  FIFO  the  cylinder  addresses 

are   a   sequence   of   samples   of   a   random   variable   uniformly 

distributed  between  1  and  the  number  of  cylinders  on  the  disk,  n. 

The  seek  distance  sequence  is  just  the  difference   of   successive 

terms   of   this  sequence.   Table  4.1  shows  possible  values  of  the 

seek  distance,  d,  as  a  function  of  pairs  of   cylinder   addresses. 

Examininq  diaqonals  of  constant  d  and  recalling  that  all  pairs  of 

successive  cylinder  addresses  are  equally  likely,  we  have 

Prob(seek   distanced)    =    1/n  d=0  (4.28) 

2 
2(n-d)/n         d=1,  2,  3,  .  . .  ,n-1 
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1 

2 

3 

4 

•  •  m 

...      n-1 

n 

1 

0 

1 

2 

3 

m  •  • 

...      n-2 

n-1 

2 

1 

0 

1 

2 

•  •  • 

...      n-3 

n-2 

3 

2 

1 

0 

1 

•  •  * 

...      n-U 

n-3 

4 

3 

2 

1 

0 

m  •  • 

...      n-5 

n-U 

n-1 

n-2 

n-3 

n-4 

n-5 

•  •  • 

0 

1 

n 

n-1 

n-2 

n-3 

n-4 

•  •  • 

1 

0 

Differences  of  Random  Cylinder  Addresses 

Table  4. 1. 


From  our  assumptions   the  seek  time   is  related   to  the  seek 

distance  by  the  relation 

t  (d)  =  0  d=0  (4.29) 

s 

=  \\)  &+\\)  d=1 ,  2,  3,  . .  •  ,n-  1 

1    0 


To  determine  the  mean  and  variance  of  the  seek  time  we  proceed 
as  follows 


n-1 
t      =      I      p(d)t(d) 

s        d=0 


(4.30) 


=    ^    (n  -1)/3n  ♦    \\>    (n-1)/n 
1  0 

2  n-1  2 

*[t    ]  =      I      p(d)t(d) 
s  d=0 

2      2  2  2 

88    ^    (n  -1)/6    ♦    2iJj    i>    (n  -1)/3n    ♦    ty    (n-1)/n 
1  10  0 

2  2      2  2  2  2 

a     -  jjl    (n  -1)  (n    »2)  ♦    2^1  ^Ofn  -1)  ♦    4*0  (n-1)         (4.31) 
s                              2                                   2  2 

18n  3n  n 


Since  the   FIPO   algorithm   does   not   disturb   the   independence 
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assumptions  of  the  stream  of  input  requests,  we  can  compute  the 
request  service  time  mean  and  variance  as  the  sum  of  independent 
random  variables.  The  transfer  time  and  rotational  latency  are 
the  same  as  for  the  drum.   Combining  them  ve  find 


t   =  t  t  t   ♦  t 
r    t    1    s 

2     2    2     2 

a  =  a  ♦a   ♦  a 
r    t    1    s 

x  =  gt 


(4.32a) 

(4.32b) 
(4.33a) 


2      2        2 
a     =  'go  ♦  (t  )  (g-1)g 
x     r     r 

p  -  Ax 


(4.33b) 


Combining  terms  and  substituting  into  Eq. 
service  time,  T,  we  ha?e 


(4.25)   for   the   bulk 


T  = 


1  ♦ 


(4.34) 


Forward  substituting  into  the  last  equation  only  obscures  the 
result.   The  core  usage  follows  just  as  in  the  drum  case 

2 


c  =  A6t  g 

r 


(4.35) 


MSCAN    Analysis 


In  the  MSCAN  policy  the  requests  comprising  each  bulk  are 
reordered  to  reduce  seek  and  latency  time  but  the  bulks 
themselves    are    served   in  first-come-first- served   order.      In   terms 
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of  the  R/6/1  queueing  system  each  balk  represents  a 
super- customer  with  a  general  service  time  distribution.  This 
distribution  is  the  sum  of  seek  times  (disks  only) ,  rotational 
latency  times,  and  transfer  times  for  all  the  requests  of  the 
bulk.  Once  the  mean  and  variance  of  the  service  time  of  each 
super-customer  is  determined  the  bulk  service  time  can  be  found 
from  the  Pollaczek-Khinchin  mean  value  formula  since  the 
super— customers  are  serviced  PIPO. 

BSCAN  Eolicy  for  Drum  Systems 

The  mean  and  variance  of  the  transfer  time  remain  unchanged. 

For  the  mean  and  variance  of  the  total  transfer  time  we  determine 

the  sum  of  a  random   number   of   identically   distributed 

statistically  independent  random  variables  and  obtain 

t   =  g6  (4. 36a) 

tt 

2     2  2 
a        =  g  6  (4.36b) 

tt 

To  determine  the  total  latency  ve  must  consider  hov  HSCiM 
schedules  requests  which  lie  on  the  same  cylinder  and  belong  to 
the  same  bulk.  In  this  case  H5CAN  uses  the  SLF  policy,  which 
requires  that  whenever  the  head  becomes  free  it  selects  the 
nearest  request  next.  Since  the  distribution  of  the  rotational 
position  of  requests  is  a  statistically  independent  random 
variable  uniform  over  [0,1),  the  latency  distribution  for  the 
initial  request  selected  is  that  of  a  minimum  of  n  samples  of  the 
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random  variable.   If  the  distribution  of  the  transfer  time  were 

such   that  the  position  of  the  head  upon  completion  of  a  transfer 

were  independent  of  it  starting  position,  this  approach  could  be 

repeated  iteratively   for   the  remaining  n-1  requests.   However, 

the  only  continuous  distribution  which  destroys  knowledge  of  its 

starting   position  completely  is  uniform  modulo  1.   For  any  other 

distribution  the  total  latency  will  not  be  independent  of  all  the 

record   positions   and   lengths.   Assuming  the   independence 

assumptions  were  met,  the  mean  and   variance  of   n  independent 

samples  would  be 

t   =  JL.  (4.37a) 

In   n*1 

2 

a   = n (4.37b) 

In        2 

(n*1)  (n*2) 

For  the   bulk  size  distribution   assumed   the  mean  and      variance     of 

the   total   latency   are 

oo  n 

t        =      [p        7     _i_  (4.38a) 

It        n=1   n   i=1   i*1 

=  3—      1    ♦   g(ln(g)-1) 

2 

(g-D 

2  «        2  «>  2 

a       =      I      a      p        ♦      I      (t     -t     )    p  (4.38b) 

tl        n=1      In  n  n=1        In      It        n 

As  was  noted,  these  equations  are  exact  only  if  the  transfer  time 
renders   the   latencies  independent.    It  can  be  shown  that  as 
increases  the  transfer  time  distribution  assured  here   approaches 
a   uniform   distribution  modulo   1.    Taking   Eg.   (4.38a)  as  an 
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approximation  for  our  values  of  6,  the  following  table  shois  the 
accuracy  obtained. 


10      20      50 


Analytic  latency 

Simulated  latency 
Percent  error 


.586" 

.253 

.173 

.113 

•  061 

.382 

.263 

.194 

.146 

.095 

0.2 

3.8 

10.8 

22.6 

35.8 

MSCAN  Latency  Approximation 
Table  4.2. 


The  independence  assumption  is  not  a  bad  approximation  for  all 
but  the  largest  bulk  size  simulated.  Combining  the  means  and 
variances  of  the  total  latency  and  total  transfer  time  to  obtain 
the  mean  and  variance  of  the  time  to  service  each  bulk,  ve  obtain 

x  -  g6  ♦  o__  [l  ♦  g(ln(g)-1)J  (4.39a) 

(g-D 

2     2  2     2 
a  =  g  6   ♦  a  (4.39b) 

x  It 

These  values  can  be  substituted  into  Eq.   (4-25)  to  find   T,   the 

MSCAN  bulk  service  time.  Core  usage  can  be  immediately  computed 
as  was  done  in  FIFO  to  show 

C  =  Xg6x  (4.40) 


MSCAN  Policy  for  Disk  Systems 

To  solve  for  the  average  bulk  service  time  for  the  MSCAN 
policy  applied  to  a  disk  system  ve  must  determine  the  seek, 
latency,  and  transfer  contributions  that  sum  to  produce  the 
service   time   of  a  bulk.   First  ve  find  the  Bean  and  variance  of 
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the  total  distance  the  head  must  move  to  service  the  entire  bulk, 
ignoring  initial  positioning,  as  a  function  of  bulk  size.  Let  us 
use  a  continuous  variable,  x,  to  approximate  the  quantized 
cylinder  position  number,  v=1 ,2,3,. •• ,n.   Clearly 

2 


Prob(min(x  ,x  ,x  ,...,x  )  <x)  «  1-(1-x) 
12  3      k 


(CDF) 


Prom  the  CDF  we  can  find  the  equivalent  PDF 

k-1 
PDF  =  CDF  =  k(1-x) 

dx 


<«».41) 


Dsing  the  same  approach  we  can  determine  the  maximum  cylinder 
position  conditioned  on  a  known  minimum  cylinder  position,  this 
gives 

Prob(max(x  ,..x  )<x|min(x  ,..x  ) =y)  =  0        x<y 

1k         1k 

k      k 

-  <x-y)  /d-y)  x>y 


PDF  =  CDF  *  0 

dx        k-1      k 
-  Mx-y)   /(1-y) 


*<y 
«>y 


(4.U3) 


By  integrating  this  last  PDF  over  x  and  y  we  can  determine  the 
moments  of  (x-y)  and  obtain  the  mean  and  variance  of  the  total 
seek  distance  ve  desire 

.2 


F[  (x-y)  |k   requests]  = 


W 


2       .2 

a  = 
d 


(h  "  (**1) 


(a.uaa) 


(U.uub) 


He  now  have  the  seek  distance  but  what  we  need  is  the  seek   time. 
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To   determine   this   ve  must  know  not  only  how  far  the  head  moves 

but  hov  many  stops  it  makes.   This  is  the  problem   of   placing   g 

distinct   balls   into  n  urns   such   that  exactly   k   urns  are 

non-empty.   With  requests  taking  the  place  of  balls  and  cylinders 

the  place  of  urns  ve  can  immediately  vrite 

k 
S  n! 

Prob  (require  k  stops  to  read  g      * g (4.45) 

requests  from  n  cylinder  disk)      g 

n  (n-k)  ! 

The  mean  and  variance  of  the  number  of  stops  are 


E[#  stops]  =  I     _I_&zil     I      * 
i=1  g-1  \g  J         k-1 


2  2  2 

a  =  E[  stops  ]  -  £[  stops]  (4.46b) 

s 

Obviously  ve  could  nov  concern  ourselves  with  the   total   latency 

given   that   ve   make   k   stops,   since   k  and  g  tell  us  hov  many 

cylinders  could  have  multiple  requests.   Instead  ve  assume  no  tvo 

requests   lie  on  the  same  cylinder.   This  approximation  should  be 

good  for  small  q,    since 

Prob  (no  2  of  g  requests  lie  on    nj. 

same  one  of  n  cylinders)    =*   g  (4.47a) 

n  (n-g)  ! 

-g 

■  e   /2  7rn/ (n-g)  (4.47b) 

The  total  seek  time  mean  and  variance  vould  then  be 

2 


st     1  lg+ll     0 


(4.48a) 
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2     2  2 

a   =  \p   n 
st    1 


(«^  "  rV 


0 


(4.48b) 


Since  ve  assumed  that  no  two  requests   vere  for  the  sane 

cylinder  ve  have  the  following  foe  the  total  latency 

t   *  g/2  (4.49a) 

It 


a   =  g(3g-2)/12 
It 


(4.49b) 


The  total  transfer  time  is  unchanged,  so  ve  have 

t    *  6g 
tt 

2     2  2 

a   -  g  6 
tt 


(4.50a) 


(4.50b) 


By  our  independence  assumptions  ve  can  sum  the  transfer,   seek, 
and  latency  time  to  get 


i  »  t   ♦  t   «•  t 

tt    st    It 

2    2     2     2 

a     =  a   ♦  a   ♦  a 
x    tt    st    It 


(4.51a) 


(4.51b) 


At  this  point  ve  have  the  necessary  terms  to  substitute  into  the 
Pollaczek-Khinchen  mean  value  formula  to  find  Tf  the  bulk  service 
time  for  HSCAN  disk.  Using  the  nev  definition  for  i,  the  core 
usage  expression  is  unchanged. 
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SBF  Policy  for  Drum  and  Disk  Systems 

The  SBF  discipline  can  be  analyzed  using  the  technique  in 
Conway  et  al  [33].  This  technique  does  require  the  assumption 
that  service  of  requests  in  the  same  priority  class  be  PIFO 
rather  than  by  minimum  total  record  length  as  we  assumed  in 
Chapter  2.  The  effect  of  this  change  should  be  slight.  Using 
the  same  M/G/1  formulation  as  HSCAN  and  identifying  all  requests 
of  one  bulk  as  a  super  customer  for  this  analysis,  let  us  assign 
=*11  LuIks  of  size  k  to  priority  class  k.  Classes  are  assigned 
indexes  in  reverse  order  of  priority;  class  1  is  the  highest 
priority.   Se  define 

A  =  arrival  rate  of  jobs  of  class  k 

k 

x  =  random  variable  for  service  time  of  class  k 
k 

p  =  X  x  =  utilization  factor  for  jobs  of  class  k 
k    k  k 

Now  each  class  can  be  viewed  as   a   separate   M/G/1   system   with 

arrival   rate    k   and  service  time  x^.   Customers  in  class  k  can 

only  be  effected  by  customers  of  higher  priority  (classes   <   k) • 

From  our  definitions  it  is  clear  that  for  the  drum  system 

k 
X  =  Xq   =  X  _1_  qz^  (4.52) 

k     k     g-1    g 

k 
x   =  k6  ♦  I     _J_  (4.53a) 

k        i=1  i+1 

2      2k 

a     =  k6   ♦  I      1 (4.53b) 

k         i=1  (k+1)  (k*2) 
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2     2 
a     ♦  7 
k    k 


k  k   g-1  [   g  / 


k«  ♦  I  -1. 
i*1  i*1 


(4.54) 


(4.55) 


He  can  now  us  Convay's  result   to  give   the   waiting  time  for 
customers  of  class  k  in  terms  of  known  quantities 


2 

I  X  x 

«  = i~l_i_A 

k        k-1       k 

2(1-  I  P  )  (1-  I    p  ) 
i=1  i    i=1  i 


(4.56) 


Immediately  we  have  that  Tk,  the  bulk  service  time  for   bulks  of 

size  k  is 

T  =  x   ♦  V  C*-57) 

k    k    k 


Since  only  the  order  in  which  bulks  are  serviced  is  effected  by 
sbf,  the  results  from  HSCAN  for  request  service  time  and  core 
usage  apply  immediately. 

The  disk  case  can  be  handled  in  exactly  the  same  manner;  it 
is  only  necessary  to  substitute  the  equations  from  the  HSCAN  disk 
analysis  to  show  that  in  this  case 

k2 


x     =   k6 
k 


♦    k/2   ♦    \\>  n/   k  \       ♦    \p  k 
1    \k*l]  0 

2  2  2    2  r        2  XU 

-    k6      ♦   k/12    +  ty  n       Lk_\    -     (  k_\ 
k  1        Hg*2j  ^g*1 


(4.58a) 


♦  *  9(9-1)  (4.58b) 
0 


Once  again  the  request  service  time  and  core  usage  are   the   same 
as  for  the  hscan  disk  case.   For  both  drum  and  disk  the  mean  bulk 
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service  time,  T,  can  be  computed  by 

T  -  J,        1_  (gzM    T  (4.59) 

i=1  g-1  ^g  /   i 


PSDP  Policy  for  Drum  and  Disk  Systems 

The  analysis  of  PSBP  parallels  that  of  SBF  with  the 
additional  complication  of  preemption.  By  our  definition 
preemption  can  occur  only  between  requests  of  a  bulk.  Por  the 
drum  case  this  clearly  makes  the  rule  preemptive  resume,  since  no 
cost  is  incured  due  to  the  interruption  at  such  points.  Por  the 
disk  case  where  the  arm  may  be  carried  off  to  satisfy  the 
requests  of  the  preempting  customer,  the  situation  is  less  clear. 
However,  for  simplicity  we  assume  preemptive  resume  is  a 
sufficient  approximation  to  actual  behavior.  Using  the  same 
definitions  for   k,  xk#  and  p^  we  can  use  Conway*s  formuula 

k   ~~2 

x  I    X   x 

T   = k ♦ iz!_i_i (4.6  0) 

k     k-1  k-1         oo    k 

1-  I    X   x     2(1-  I    X   x  )  (1-  I    X   x  ) 
i- 1  i  i        i=  1  i  i    i=1  i  i 

to  find  the  bulk  service  time  for  bulks  of   size   k.    The   bulk 
service  time  summed  over  all  k  and  weighted  is  just 

.k 


T  = 


hT   =   I  _1_/3z1)t  (4.61) 

i=1  i  i    i=1  g-1  V  9  /  * 


The  request  service  time  should  be  unchanged  from  that  of  MSCAN, 
since  individual  requests  are  not  interrupted  by  preemption. 
From  Eq.   (4.10)  we  can  see  that 
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C   «  X  I  96  (<».62) 

i     i  i 


C  =   J  X  5  g6 
1*1  i  i 


oo        i 

-1  i=H  g  J  i 


g 


SCAN  RQliS.1   i2£  P£jij5  and  ]>is&  Systems 

The  analyses  presented  to  this  point  have  hinged  on  being 
able  to  define  a  super  customer  in  a  manner  such  that  the  system 
can  be  modeled  as  an  M/G/1  system.  This  has  been  possible 
because,  to  a  first  approximation,  super  customers  so  defined 
were  independent.  In  the  SCAN  algorithm  the  time  to  service  a 
request  Is  an  explicit  function  of  the  number  of  available 
requests  or.  In  other  vords,  the  queue  length.  This  behavior 
does  not  conform  to  the  N/G/1  model  nor  the  simple  responsive 
server  model,  M/fl/°°.  In  fact,  since  the  uunf inished  vork  in  the 
SCAN  system  Is  not  conserved,  even  a  G/G/1  model  is 
insufficiently  powerful. 

To  illustrate  the   problem  let   us   determine  the   request 

service   time,   conditioned   on   k  requests  in  the  queue,  for  the 

drum.   Por  the  drum  case,  ve  have   the   transfer   time   plus  the 

latency,   given   k   requests.    Again  we  call  on  an  independence 

assumption  which  ve  know  is  only  an  approximation.   le  have 

t  =  t   ♦  t   »  6  ♦  J_  (4. 63a) 

r    t    1       k*1 
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2     2 

o=6* k (4.63b) 

r  ~2 

(k*1)  (k*2) 


To  solve  for  the  queueing  time  we  must  in  effect  determine 
the  probability  of  the  queue  containing  k  requests  for  all  k>0. 
To  determine  these  probabilities  ve  need  the  request  service  time 
but  this  is  a  function  of  the  queue  length  k.  He  must  know  k  to 
find  k!  With  suitable  numerical  techniques  we  could  obtain  an 
approximate  solution  for  the  distribution  of  the  queue  length. 
However  the  resulting  procedure  would  provide  little  additional 
insight  into  the  behavior  of  the  system  not  already  obtained  by 
simulation.  In  fact  the  simulation  is  a  form  of  Monte  Carlo 
solution  to  the  above  problem. 

Analytic  Conclusions  and  Insights 

From  the  results  in  this  chapter  we  can  confirm  several 
observations  made  in  Chapter  3.  Clearly  the  core  usage,  C,  for 
FIFO,  MSCAN,  and  SBF  will  grow  linearly  with  arrival  intensity 
(see  Figures  3.7c  and  3.8c  for  example)  froff  examination  of  the 
analytic  forms  for  C.  It  is  also  apparent  from  our  argument  that 
core  usage  for  MSCAN  and  SBF  must  be  identical.  Since,  for  a 
given  bulk  size,  PSBF  can  only  increase  the  time  between  the 
first  and  last  request  of  a  bulk,  core  usage  for  PSBF  can  not  be 
less  than  SBF  and  probably  will  be  more. 
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Table  4.3  shovs  a  comparison  of  the  simulation  and  analytic 
predictions  for  bulk  service  time,  request  service  time,  and  core 
usage.  The  first  column  of  the  table  indicated  how  many  times 
the  simulation  and  analytic  models  agreed  on  the  stability  or 
instability  of  cases.  For  all  but  PSBF  disk  the  two  methods 
produce  excellent  agreement.  The  ratios  shown  for  bulk  service 
time,  request  service  time,  and  core  usage  indicate  the  average 
value  obtained  by  simulation  over  the  value  obtained  by  analysis 
or  vice  versa,  such  that  each  ratio  is  one  or  greater.  This 
procedure  produces  unbiased  results  as  neither  simulated  or 
analytic  values  are  used  as  reference  points.  For  request 
service  time  the  ratio  is  consistently  very  nearly  1.000, 
indicating  very  good  agreement  between  simulation  and  analysis. 
This  close  agreement  vindicates  the  approximations  that  Me  made 
in  the  ttSCAN,  SBF,  and  PSBF  analyses.  Bulk  service  time  also 
shovs  good  agreement  except  for  PSBF  and  FIFO  disk  vhere  results 
could  be  characterized  as  fair.  For  PSBF  discrepancies  are 
likely  due  to  the  simulation  since  tail  effects  may  or  may  not  be 
accurately  reflected  in  a  short  simulation  run.  PSBF  is 
extremely  sensitive  to  this  for  bulk  service  time  due  to  the 
discrimination  against  larger  bulks.  Core  usage  results  are  in 
excellent  agreement  except  for  PSBF.  Hand  analysis  of  PSBF 
comparisons  shov  simulated  results  are  uniformly  less  than 
analytic  results  by  about  the  ratio  given  in  the  table. 
Sensitivity  to  extreme  cases  in  the  simulations  would  seem  to  be 
ruled  out  as  a  more  random  relationship  would  be  expected.  A 
flaw  in  analysis  or  programming  can  not  be  ruled  out. 
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Stabi 

lity 

Bulk 

Request 

Core 

predictions 

service 

service 

usage 

agree 

<120) 

time 

time 

PIFO  Drum 

118 

1.062 

1.003 

1.037 

FIFO  Disk 

116 

1.306 

1.003 

1.040 

MSCAN  Drum 

119 

1.113 

1.034 

1.101 

MSCAN  Disk 

119 

1.124 

1.032 

1.075 

SBF  Drum 

119 

1.087 

1.035 

1.101 

SBF  Disk 

115 

1.145 

1.041 

1.062 

PSBF  Drum 

119 

1.238 

1.036 

1.513 

PSBF  Disk 

110 

1.331 

1.048 

1.645 

Comparison  of  Simulation  and  Analytic  Results 

Table  4.3. 


Overall  the  comparison  of  analytic  and  simulation  results  is 
very  good.  This  increases  confidence  in  both  sets  of  results. 
While  the  analytic  results  are  computationally  superior, 
requiring  less  than  two  minutes  of  machine  time  to  evaluate  960 
cases,  the  twenty-one  hours  of  simulation  required  for  the  same 
960  cases  did  provide  additional  results  on  shapes  of 
distributions  and  higher  moments.  Simulation  was  also  able  to 
handle  the  SCAN  algorithm  which  proved  difficult  to  analyze. 
Together  they  provided  complementary  tools  for  the  work  that  was 
performed. 
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Chapter  5 

REVIEW,  CONCLUSIONS,  AND 

SUGGESTIONS  POE  PUTDBE  RESEARCH 

In  this  thesis  the  problem  of  scheduling  accesses  to  a 
rotational  storage  device  in  the  context  of  a  timeshared 
information  retrieval  system  has  been  defined.  A  model  which  is 
consistent  with  statistics  of  an  operational  system,  MEDLINE,  has 
been  developed.  Several  scheduling  algorithms  have  been  proposed 
and  measurements  of  their  effects  on  system  performance  have  been 
defined.  Dsing  the  MEDLINE  data,  the  model,  and  the  scheduling 
and  measurement  definitions,  a  simulator  has  been  designed, 
coded,  debugged,  and  run  to  produce  graphic  and  tabular  results 
on  the  performance  of  the  algorithms.  The  performance  of  the 
algorithms  have  been  qualitatively  and  quantitively  compared. 
Whenever  possible  the  model  has  also  been  analyzed  analytically. 
The  simulation  and  analytic  results  have  been  compared  and  found 
in  excellent  overall  agreement. 

The  result  of  both  simulation  and  analytic  studies  is  that 
the  best  overall  algorithm  is  SBF.  Recall  from  Chapter  2  that 
this  algorithm  serves  one  bulk  at  a  time,  shortest  bulk  first. 
Within  each  bulk  requests  are  ordered  to  reduce  seek  distance  and 
rotational  latency.  SBF  combines  good  bulk  service  time  with  lov 
buffer  usage.  PSBP  provides  slightly  better  bulk  service  time 
but  exhibits  greater  than  linear  growth   of   buffer   usage   which 
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leads  to  unfavorable  overall  performance  at  large  arrival  rates. 
SCAN  exhibits  even  faster  buffer  usage  growth  than  PSBP  and 
produced  poor  bulk  service  times  due  to  excessive  interleaving  of 
requests  of  different  bulks.  HSCAN  produces  core  usage  identical 
to  S6F  but  has  larger  bulk  service  time  because  it  takes  no 
advantage  of  the  distribution  of  bulk  sizes.  FIFO  performance  is 
generally  poor  at  all  but  the  lowest  arrival  rates  and  smallest 
bulk  sizes  due  to  its  naivete.  It  does  outperform  SCAN  in  terms 
of  buffer  usage  under  heavy  loads  but  only  until  it  saturates. 

The  data  collected  during  the  simulations  and  the  analytic 
expressions  obtained  may  also  be  used  to  consider  the  merits  of 
the  five  algorithms  under  other  conditions  or  a  subset  of  the 
conditions  studied.  The  conclusions  made  over  the  whole  range  of 
conditions  studied  may  not  hold  for  special  cases  of  interest. 
This  work  does  provide  the  foundation  future  study  in  this  area. 

The  magnitude  of  the  three  performance  measurements  for  the 
five  scheduling  algorithms  differ  by  less  than  a  factor  of  ten  in 
all  cases.  However  in  the  systems  being  modeled  changes  of  less 
than  a  factor  of  two  can  dramatically  effect  the  overall 
performance  of  the  system.  This  is  especially  true  in  regard  to 
the  merge  processor,  which  when  poorly  used  can  severely  degrade 
performance  as  was  the  case  in  the  Stellhorn  multiuser 
simulations  that  sparked  this  work.  Since  the  complexity  of 
these  algorithms  is  manageable  even  in  a  minicomputer  based 
system  there  is  no  excuse  for  suffering  the  performance  penalties 
imposed  by  an  incorrect  choice  of  access  scheduling  algorithm. 
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He  have  proved  that  under  conditions  which  closely 
approximate  an  actual  system  the  scheduling  algorithm  known  to 
provide  minimal  service  time  in  non-bulk  arrival  systems,  scan, 
is  a  poor  choice.  He  have  determined  why  SCAM  behaves  poorly  and 
have  found  another  algorithm,  SBF,  which  consistently  outperforms 
it.  Results  which  allow  generalization  or  specialization  of  our 
findings  to  other  conditions  have  been  developed.  Data  on  the 
performance  of  an  actual  system  has  been  collected  and  analyzed. 
This  data  can  provide  a  foundation  for  almost  any  investigation 
in  the  area  of  large  interactive  information  retrieval  systems. 

The  results  of  this  thesis  need  not  be  restricted  to  the 
domain  defined  in  Chapter  2,  that  of  a  timeshared  information 
retrieval  system.  The  essential  assumptions  of  bulk  arrivals  and 
the  blocking  of  some  processor  until  all  the  requests  of  a  bulk 
are  serviced  are  met  by  other  systems.  Examples  include  most 
inverted  file  or  database  systems,  timesharing  systems  with 
pre-paging,  swapping  systems  using  shared  pure  procedures,  and 
scatter- gat  her  read/write  devices.  Given  these  basic  conditions 
it  appears  the  arguments  advanced  and  conclusions  reached  can  be 
extended. 

Suggestions  for  Future  Work 

Two   interrelated   extensions  of   the   present    work  are 

consideration   of   channel  utilization  and  multiple  devices.  Let 

us  define  the  channel  utilization  for  a  given   algorithm   as  the 

ratio   of   transfer  time  to  request  service  time.   As  Figures  5.1 
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and  5.2  illustrate,  this  is  a  function  of  device  type  and 
scheduling  algorithm.  Channel  utilization  provides  a  measure  of 
the  efficiency  of  an  algorithm  and  could  be  used  to  rate 
algorithms.  It  also  provides  an  estimate  of  the  amount  of  time  a 
channel  would  be  required  by  an  active  device.  Using  this 
information,  arrival  rates,  and  the  core  usage  and  bulk  service 
time  from  the  current  work,  a  model  of  a  multiple  device  system 
can  be  constructed  and  analyzed.  Questions  about  numbers  of 
devices  per  channel,  channel  capacities,  multiply  connected 
devices,  and  general  system  architecture  can  be  considered- 
Performance  prediction  and  system  reconfiguration  for  new  and 
existing  systems  can  also  be  studied. 

The  NEDLINE  data  referred  to  in  this  work  and  detailed  in 
Appendix  A  provides  a  wealth  of  information  about  an  actual 
system.  The  data  deserves  more  direct  consideration  for  the 
information  it  can  provide  on  query  structure,  user  behavior,  and 
system  behavior.  A  careful  study  and  clever  analysis  would  go  a 
long  way  toward  providing  a  clear  definition  of  the  process  of 
information  retrieval  as  it  is  actually  practiced.  Models  can 
then  be  built  based  on  what  is  rather  than  what  might  be. 

A  series  of  open  questions  concerns  what  might  be  rigorously 
proven  about  the  relative  performance  of  the  algorithms  defined 
here.  By  extracting  essential  behavioral  characteristics  it  may 
be  possible  not  only  to  prove  the  relative  merits  of  each  of  the 
five  algorithms  but  also  determine  necessary  traits  of  even 
better   algorithms.    Such   results  could  direct  the  synthesis  of 
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new  algorithms.  An  attempt  to  discover  a  simple  structure 
underlying  what  appears  to  be  a  horribly  complex  set  of 
interactions  should  be  considered.  The  prospects  for  success 
seem  slight  but  the  potential  benefits  are  undeniable. 
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Appendix  A 
HEDLINE  STUDY 

To  accurately  model  and  analyze  the  behavior  of  the 
secondary  storage  sub-system  of  an  interactive  information 
retrieval  system,  ve  must  be  able  to  specify  how  such  a  system  is 
driven  by  its  users.  To  this  end,  amoung  others,  it  vas 
desirable  to  study  the  actual  operating  data  of  such  a  system. 
Several  basic  questions  Here  formulated  and  data  vhich  might 
answer  them  vas  gathered.   The  principal  questions  asked  were: 

1)  What  does  a  query  look  like? 

-how  many  terms  per  query 
-what  kinds  of  terms  are  used  and  how 
-what  connectives  are  used  and  how 
-how  large  are  query  results 

2)  What  are  the  characteristics  of  terms  and 
connectives? 

-postings  per  term 
-overlap  of  terms  as  a  function  of 
connective 

3)  How  does  a  user  behave? 

-how  long  does  he  work 
-how  fast  does  he  work 
-how  much  does  he  work 
-how  does  he  chain  his  searches 
together 

U)  How  does  system  behave 

-user  load  in  number,  requests, 

and  messages 
-system  response  to  searches  and 

other  reguests 
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To  answer  all  these  questions  ve  required  a  machine  readable 
log  of  all  messages  to  and  from  MEDLINE,  the  number  of  postings 
associated  with  each  term,  and  the  tree  structured  index  term 
vocabulary  (fleSH)  .  Through  the  offices  of  Davis  HcCarn  of  NLfl  we 
obtained  a  transaction  tape  which  partially  satisfied  our  first 
need.  Data  on  the  number  of  postings  for  each  index  term  was 
unavailable,  as  was  a  machine  readable  HeSH.  A  HeSH  tree 
structures  book  [28]  for  use  by  indexers  and  users  was  obtained. 
To  answer  the  question  of  how  the  distribution  of  index  terms 
that  are  actually  used  (dynamic  index  terms)  differs  from  the 
static  index  term  distribution,  or  Zipf  curve,  modifications  were 
made  to  our  inhouse  system,  EUREKA,  to  attempt  to  develop  this 
data.  Unfortunately,  usage  was  insufficient  to  build  up 
meaningful  data  by  the  time  of  this  writing. 

The  machine  readable,  and  hence  easily  digestible,  MEDLINE 
data  available  was  just  a  single  day*s  traffic  file,  covering  the 
period  from  12:45AM  to  7:40PM  on  Monday,  January  13,  1975.  Due 
to  the  widespread  use  of  the  system,  including  Europe,  and  the 
nature  of  computer  users,  the  system  was  loaded  over  the  complete 
time  span.  The  tape  we  received  contained  38,651  records,  of 
which  only  the  first  38,799  could  be  correctly  transferred  to  a 
second  tape  by  the  CSO  IBM  360/75.  Bach  record  contained  the 
information  shown  in  Table  A. 1. 


Postj-pn 

i-e~ 

I 

9 

10- 

12 

13 

14- 

•18 

19 

20- 

■26 

27 

28- 

•29 

30 

31- 

•32 
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Terminal  I.  D.  (user  signon  name) 

blank 

TSO  line  number 

blank 

YYDDD  -  Julian  date 

blank 

HHNMSST  -  Military  time  in  hours,  minutes, 

seconds,  and  tenths 

blank 

unused 

blank 

Hexidecimal   zero   if   an  input    record,    non-zero 

if  an  output  record 

33  Blank  if  input  record,  first  character  of  message 
if  output  record 

34  Hexidecimal  length  of  message  if  input  record, 
second  character  of  message  if  output  record 

35  First  character  of  message  if  input  record,  third 
character  of  message  if  output  record 

36-89      Up  to  next  54  characters  of  message  -  input  records 
may  contain  C'$*  which  erases  the  whole  message  or 
X'EI1  which  rubs  out  the  preceding  non-X'H1 
character 

P1EDLINE  Tape  Format 
Table  A. 1. 


Because  at  most  the  first  57  characters  of  each  output 
message  and  55  or  less  characters,  depending  on  rubouts  and  line 
kills,  of  the  input  messages  appear  in  the  traffic  file,  not  all 
messages  can  be  classified  and  processed.  Such  messages  are  here 
referred  to  as  truncated  messages.  Fortunately  the  input  message 
records  contain  a  character  count  which  allows  the  detection  of 
truncated  messages,  since  by  definition  they  contain  more 
characters  than  fit  in  the  buffer.  However,  since  the  buffers 
aren't  cleared  before  being  reused  and  output  messages  have  no 
embedded  length  count,  undetectable  cases  can  occur  in  output 
message  analysis.  These  problems  are  most  severe  on  search 
statement    input    messages   and   search   result   messages   when 
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displayed  in  'long'  mode  [26]. 

The  program  which  collects  statistics  to  answer  as  many  of 
the  guestions  posed  earlier  as  possible  simply  pretends  it  is 
hedline.  User  input  messages  are  scanned  for  editing  action 
characters  to  produce  clean  messages.  Tables  are  updated  using 
the  message  content  and  time  stamp  included  in  each  record. 
Messages  which  reguest  LOGIN  or  LOG00T  allocate  or  deallocate 
table  space  for  a  given  user.  The  terminal  I.D.  field  that 
appears  in  every  message  is  used  to  associate  messages  with 
users.  Output  messages  are  analyzed  to  see  what  the  real  MEDLINE 
did;  the  model  follows  accordingly,  recording  statistics  as  it 
goes.  Since  the  state  of  the  simulated  HEDLINE  machine  is 
unknown  when  the  transaction  tape  begins  and  ends,  the  results 
may  be  biased  by  the  startup  and  shutdown  assumptions  made  in  the 
model.  These  assumptions  are  that  there  are  no  users  at  startup 
and  that  all  users  are  forced  to  logout  at  shutdown.  In  all  the 
measurements  that  follow  a  sample  size  is  indicated.  For 
statistics  with  large  sample  sizes  the  boundary  conditions  and 
embedded  pathological  cases  should  be  less  significant  in  the 
final  result.  The  acid  test  of  the  results  given  here  would  be 
to  run  tapes  of  several  other  days  through  the  program  and 
compare  the  results.  This  has  not  been  done  as  interest  in  these 
results  aside  from  the  current  author  have  been  nil. 

Since  neither  a  MeSH  tape  or  postings  count  list  was 
available  directly  in  machine  readable  form  for  MEDLINE, 
alternate  approachs  were  taken  to  gain  some  knowledge  about  index 
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postings  sizes.  For  searches  that  referred  to  only  one  term  the  # 
number  of  postings  in  the  result  is  trivially  the  same  as  the 
number  of  postings  of  the  term.  Distributions  for  single  term 
searches  for  each  term  class  were  collected  to  approximate  the 
dynamic  distribution  that  could  have  been  obtained  by  using  the 
postings  count  of  each  individual  term  of  every  search.  This 
approximation  ignores  the  thorny  guestion  of  whether  or  hov  the 
dynamic  usage  of  terms  varies  as  a  function  of  the  complexity  of 
the  search.  To  determine  the  number  of  basic  index  terms  which 
an  actual  exploded  term  called  up,  all  exploded  terms  were 
extracted  from  the  tape  and  looked  up  in  the  fleSH  [28]  by  hand 
vhere  the  number  of  lover  level  terms  vere  counted. 

What  follows  are  the  tables  and  graphs  of  the  analysis 
results,  a  discussion  of  the  answers  these  results  provide  to  the 
questions  at  the  beginning  of  this  appendix,  the  questions  yet  to 
be  answered,  and  questions  raised  by  the  answers  to  date.  A 
glossary  of  terms  used  in  this  appendix  is  provided,  along  vith  a 
sample  transaction  tape  listing.  Figure  A. 14- 
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Parameter 

E[x] 

a 

X 

min 

max 

sample 

figure 

logged  in  users 

8.54 

6.72 

0 

25 

25 

A.1 

search  request 

11.24sec 

24.84 

0 

600 

4340 

A. 2 

interarrival  time 

real  search 

11.83sec 

27.42 

0 

250 

4058 

1.3 

completion  time 

search  completion 

1.01 

1.94 

0 

25 

4058 

A. 4 

CPD  time 

input  messages 

20.21 

12.71 

1 

59 

793 

per  minute 

output  messages 

29.71 

19.24 

0 

94 

793 

per  minute 

system  response 

3.90sec 

4.51 

0 

35 

14972 

A.  5 

time 

MEDLINE  System  Statistics 
Table  A. 2. 


Parameter 

E[x] 

a 

X 

min 

max 

sample 

figure 

session  time 

16.30min 

25.09 

0 

200 

525 

searches  per  session 

7.70 

12.96 

0 

100 

525 

A. 6 

searches  per  minute 

0.63 

0.38 

0 

3 

525 

per  user 

input  messages  per 

30.27 

44.73 

0 

390 

525 

session 

output  messages  per 

44.29 

64.72 

0 

570 

525 

session 

user  response  time 

28. 15sec 

29.54 

0 

200 

14476 

A.7 

MEDLINE  User  Statistics 
Table  A.  3. 


Parameter 

E[x] 

a 

X 

min 

max 

sample 

figure 

terms  per  search 

1.92 

0.99 

1 

8 

4334 

A. 8 

statement 
basic  terms  per 

30.25 

50.97 

0 

250 

650 

A.  9 

exploded  term 
single  normal  term 

573.79 

1164.26 

0 

5000 

958 

A.  10 

postings 
exploded  term 

2221.90 

1923.97 

0 

5000 

258 

A.  11 

postings 
search  statement 

273.55 

924.33 

0 

5000 

63 

A. 12 

term  postings 
search  result 

687.75 

1398.28 

0 

5000 

4141 

A.  13 

MEDLINE  Query  Statistics 
Table  A. 4. 
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Number  of 

Terms 

in  Search 

Term  type 

1 

2 

3 

4 

5 

6 

7 

8 

Total 

normal 

1194 

1866 

924 

486 

66 

110 

7 

32 

4685 

explode 

293 

227 

101 

51 

1 

4 

3 

0 

680 

ss  number 

77 

1941 

295 

363 

108 

132 

18 

32 

2966 

Total 

1564 

4034 

1320 

900 

175 

246 

28 

64 

8331 

Term  Osage  in  Queries 
Table  A. 5. 


Number  of  Terms  in  Search 


Term  type 

1 

2 

3 

4 

5 

6 

7 

8 

Total 

normal 
explode 
ss  number 

76.3 

18.7 

4.9 

46.3 
5.6 

48.1 

70.0 

7.7 

22.3 

54.0 
5.7 

40.3 

37.7 

0.6 

61.7 

44.7 

1.6 

53.7 

25.0 
10.7 
64.3 

50.0 

0.0 

50.0 

56.2 

8.2 

35.6 

Percent  Osage  of  Terms  in  Queries 
Table  A. 6. 


Number  of 

Terms 

in  Search 

Connective 

1 

2 

3 

4 

5 

6 

7 

8 

Total 

AND 

0 

1367 

221 

225 

39 

98 

9 

25 

1984 

OP 

0 

448 

576 

405 

97 

96 

15 

28 

1665 

AND  NOT 

0 

184 

40 

37 

1 

11 

0 

4 

277 

Total 

0 

1999 

837 

667 

137 

205 

24 

57 

3926 

Connective  Usage  in  Queries 
Table  A. 7. 


Connective 

1 

2 

Number  of 
3     4 

Terms 
5 

in  Search 
6     7 

8 

Total 

AND 

OR 

AND  NOT 

0.0 
0.0 
0.0 

68.4 

22.4 

9.2 

26.4 

68.8 

4.8 

33.7 

60.7 

5.5 

28.5 

7  0.8 

0.7 

47.8 

46.8 

5.4 

37.5 

62.5 

0.0 

43.9 

49.1 

7.0 

50.5 

42.4 

7.1 

Percent  Osage  of  Connectives  in  Queries 
Table  A. 8. 
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Total  Number  of  Terms  in  Query 


t  Terms 

1 

2 

3 

4 

5 

6 

7 

8 

Total 

370 

667 

59 

49 

13 

5 

2 

1 

1166 

0 

1271 

1823 

365 

197 

34 

39 

3 

8 

3740 

1487 

603 

290 

85 

6 

3 

0 

1 

2475 

1194 

834 

60 

8 

4 

1 

0 

0 

2101 

1 

293 

161 

54 

15 

1 

0 

0 

0 

524 

77 

887 

55 

6 

1 

0 

0 

0 

1026 

0 

516 

99 

90 

5 

3 

0 

0 

713 

2 

0 

33 

16 

8 

0 

2 

0 

0 

59 

0 

527 

45 

87 

6 

0 

0 

0 

665 

0 

0 

222 

14 

6 

29 

1 

0 

272 

3 

0 

0 

5 

0 

0 

0 

1 

0 

6 

0 

0 

50 

5 

5 

30 

1 

0 

91 

0 

0 

0 

64 

1 

1 

1 

6 

73 

4 

0 

0 

0 

5 

0 

0 

0 

0 

5 

0 

0 

0 

42 

5 

3 

2 

6 

58 

0 

0 

0 

0 

6 

0 

0 

0 

6 

5 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

12 

0 

0 

0 

12 

0 

0 

0 

0 

0 

2 

0 

0 

2 

6 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

5 

0 

0 

5 

0 

0 

0 

0 

0 

0 

0 

0 

0 

7 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

1 

0 

1 

0 

0 

0 

0 

0 

0 

0 

1 

1 

8 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

1 

1 

1564 

2017 

440 

225 

35 

41 

4 

8 

normal 

Total 

1564 

2017 

440 

225 

35 

41 

4 

8 

Explode 

1564 

2017 

440 

225 

35 

41 

4 

8 

SS  Number 

Note:  347  searches  were  truncated  out  of  4334 


Term  Type  Usage  Distribution 
Table  A. 9. 
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t  Conns 

1 

Total  Number  of 
2      3      4 

Terms 
5 

in 

6 

0 

1564 
1563 
1564 

650 
1550 
1833 

297 
110 
403 

107 

11 

203 

16 
2 

34 

5 

0 

32 

1 

0 
1 
0 

1367 

448 
184 

65 
38 
34 

15 

107 

9 

4 
1 
1 

0 
2 

7 

2 

0 
0 
0 

0 

19 

0 

78 

269 

3 

99 
11 
11 

12 

12 

0 

10 

33 

2 

3 

0 
0 
0 

0 
0 
0 

0 

23 

0 

4 

92 

2 

1 

4 
0 

26 

1 
0 

4 

0 
0 
0 

0 
0 
0 

0 
0 
0 

0 
4 
0 

2 

15 
0 

0 
0 
0 

5 

0 
0 
0 

0 
0 
0 

0 
0 

0 

0 
0 
0 

0 
1 
0 

0 
5 
0 

6 

0 
0 
0 

0 
0 
0 

0 
0 
0 

0 
0 

0 

0 
0 
0 

0 
0 
0 

7 

0 
0 
0 

0 
0 
0 

0 
0 

0 

0 
0 
0 

0 
0 
0 

0 
0 
0 

Total 

1564 
1564 
1564 

2017 
2017 
2017 

440 
440 
440 

225 
225 
225 

35 
35 
35 

41 
41 
41 

8  Total 


1 

0 
4 

1 
0 
5 

2641 
3236 

4078 

0 
0 
0 

0 
0 
2 

1451 
597 
237 

0 
0 
0 

0 
1 
1 

199 

345 

17 

3 
3 
0 

3 
5 

0 

37 
128 
2 

0 
0 
0 

4 

1 
0 

6 

20 

0 

0 
0 

0 

0 
0 
0 

0 
6 
0 

0 

1 

0 

0 
0 
0 

0 

1 
0 

0 
0 
0 

0 

1 

0 

0 

1 

0 

4 
4 
4 

8 
8 
8 

AMD 
OB 

AID  NOT 

Note:  347  searches  were  truncated  out  of  4  334.  Below  diagonal 
elements  are  due  to  truncated  searches,  since  in  complete 
searches  the  number  of  connectives  is  one  less  than  the 
number  of  terms. 


Connective  Type  Usage  Distribution 
Table  A. 10. 
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A  central  result  of  the  MEDLINE  study  is  some  detailed 
information  on  the  nature  of  usee  queries.  Since  the  purpose  of 
this  thesis  is'  to  analyze  a  portion  of  a  system  designed  to 
process  queries,  an  understanding  of  the  nature  of  queries  will 
define  the  work  the  system  must  handle.  Individual  queries  tend 
to  be  small  in  size,  averaging  1.92  terms.  Each  term  corresponds 
to  one  postings  list,  with  the  exception  of  exploded  terms.  Each 
exploded  term  in  a  query  produces  an  average  of  30.25  basic 
(non-exploded)  terms.  Since  exploded  terms  make  up  only  8.2%  of 
all  terms  observed,  the  effective  average  number  of  basic  terms 
per  query  is  6.50;  meaning  each  query  produces  6.50  postings 
lists  on  average.  The  standard  deviation  of  the  number  of 
postings  resulting  from  a  single  query  is  6. 40,  so  assuming  a 
normal  distribution,  95%  of  all  queries  should  reguire  less  than 
20  postings.  Using  the  geometric  distribution  assumed  in  Chapter 
2,  95%  of  all  queries  would  require  18  or  less.  Note  that  if  the 
measured  mean  of  6.50  is  used  to  compute  the  standard  deviation 
of  the  geometric  distribution,  the  result,  5.98,  is  in  good 
agreement  with  the  measured  value  of  6.40.  One  might  wonder  if 
the  apparent  small  size  of  queries  is  truly  a  user  characteristic 
or  merely  a  manifestation  of  a  bias  in  system  behavior  in  favor 
of  small  queries.  Two  facts  and  a  notion  seem  to  refute  this 
possibility.  First,  the  small  number  of  terms  per  query  is 
consistent  with  results  of  EUREKA  user  studies.  Second,  35.6%  of 
all  terms  used  in  queries  in  the  MEDLINE  data  were  of  the  search 
statement  number  variety.  Terms  of  this  type  recall  the  result 
of  an  earlier  search  (by  its   number)   for   use   in  the   present 
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search.  This  observation  meshes  with  the  notion  that  people 
solve  problems  by  making  and  reaching  subgoals  on  the  way  to  the 
final  goal.  While  the  length  or  depth  of  the  average  chain  or 
tree  of  queries  was  not  measured  directly  from  the  data,  simple 
estimation  approximations  based  on  only  chaining  result  in  an 
estimate  of  3.09  gueries  per  intellectual  search.  HEDLINE  users 
are  encouraged  to  perform  only  one  such  intellectual  search  per 
session.  The  measured  average  number  of  gueries  per  session  is 
7.70,  which  does  not  conflict  with  the  chain  approximation  and 
leaves  room  for  false  starts  in  the  intellectual  search.  Data  in 
Tables  A. 5,  A. 6,  and  A. 9  show  how  the  types  of  terms  vary  as  a 
function  of  the  length  of  gueries.  Single  term  gueries  perform 
no  explicit  logic;  they  only  report  the  number  of  documents 
linked  to  the  term.  The  relatively  high  usage  of  normal  and 
exploded  terms  in  single  term  gueries  reflects  this  probing 
behavior.  Use  of  search  statement  number  terirs  is  low  as  this 
only  serves  to  refresh  the  user's  memory  on  the  results  of  an 
earlier  query.  Use  of  exploded  terms  drops  off  rapidly  as  the 
number  of  terras  in  the  guery  grows  (data  for  7  and  8  term  gueries 
is  suspect  due  to  small  sample  size  and  truncation  effects). 
Queries  of  two  or  more  terms  appear  to  mix  new  terms  and  old 
results  in  roughly  equal  measure.  This  process,  depending  on  the 
connectives  used,  would  add  or  remove  documents  from  the  evolving 
result. 

Tables  A. 7,  A. 8,  and  A. 10  depict  the  types  of  connectives 
used  as  a  function  of  the  number  of  guery  terras.  The 
intersecting  connective  (AND)  dominates   the   two   term  gueries; 
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which  correspond  to  reducing  the  size  of  the  evolving  result. 
Queries  of  three  or  more  terms  are  dominated  by  the  union 
connective  (OR) ,  which  increases  the  size  of  the  evolving  result. 
That  the  average  query  size  is  1.92  seems  to  imply  that  users 
generally  probe  single  postings  and  combine  two  postings  in  a 
reducing  manner.  This  behavior  corresponds  to  the  winnowing  out 
function  that  information  retrieval  systems  are  intended  to 
perform.  The  relative  complement  connective  (AND  MOT) ,  also  a 
reducing  connective,  sees  relatively  little  use.  what  use  it 
does  see  is  principally  in  two  term  queries. 

The  nature  of  the  postings  lists  produced  and  consumed  by 
the  MEDLINE  system  provide  some  guidance  in  assumptions  on  disk 
and  merger  operations.  The  shape  of  the  distribution  for  result 
postings  lists  appears  exponential  with  a  very  long  tail. 
Distributions  for  the  postings  sizes  of  the  three  term  types  are 
not  directly  available,  since  data  on  the  postings  size  of  each 
term  in  the  MeSH  was  unavailable.  However,  these  distributions 
were  approximated  by  tabulating  data  on  all  single  term  searches; 
in  these  searches  what  comes  out  as  a  result,  which  is  available, 
is  just  what  went  in.  Note  that  the  distribution  of  the  postings 
terms  actually  used  in  queries  need  not  be  the  same  as  the  static 
distribution  of  all  terms  in  the  MeSH.  In  fact,  there  is 
evidence  that  terms  of  extreme  high  and  low  postings  counts  in 
the  MeSH  are  infrequently  used.  Attempts  to  accurately  study 
this  effect  were  thwarted  by  lack  of  necessary  data.  Lack  of 
data  also  made  it  impossible  to  measure  the  overlap  factor  of 
postings  lists  actually  used  for  each  of  the   three  connectives. 


Prom   the   definitions   of   the  operations,   the   factors  can  be 

bounded  as  follows,  where  |x|  means  the  length  of  list  x: 

c  =  a  and  b  0  <  |c|  <  rain  ( I a| , | b| ) 

c  =  a  or  b  max  (|a| ,Jb| )  <  |c |  <  |a|  ♦  | b| 

c  -  a  and  not  b  max  (0,  j aj- | b|)  <  |c|  <  |a| 

These  bounds  demonstrate  that  and  and  and  not  generally 
reduce  the  size  of  the  result  relative  to  their  inputs,  while  or 
generally  increases  it.  A  detailed  study  of  actual  gueries  where 
input  and  result  postings  sizes  are  known  could  provide 
functional  forms  and  coefficients  to  approximate  |c|  for  all 
three  connectives.  This  would  be  of  value  in  estimating  storage 
requirements  and  merge  patterns  for  coordination  of  lists. 
Observe  that  the  results  of  an  and  or  and  not  can  be  built  in  the 
space  required  by  one  of  its  arguments,  while  no  such  scheme 
appears  possible  for  or.. 

User  data  shows  a  pattern  of  short  sessions  (16.30  minutes 
average)  in  which  a  fair  amount  of  work  (7.7  searches  average)  is 
done.  This  reflects  the  MEDLINE  policy  of  performing  one 
preconceived  intellectual  search  at  each  terminal  session.  The 
user  comes  to  the  system  with  a  veil  thoughtout  guestion  and 
perhaps  some  offline  preparation  using  the  MeSH  books  [27,28]. 
The  user  directs  an  average  of  30.27  messages  to  the  system, 
while  the  system  produces  an  average  of  44.29  messages  for  the 
user.  The  user  response  time  is  28.15  seconds,  with  a  standard 
deviation  of  29.54.  It  is  of  some  interest  that  this  user  "think 
and  type"  time  is  not  significantly  different  than  that  which 
Scherr   found   for   CTSS   [10].   The  basic  characteristics  of  the 
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interactive  use  seem  to  carry  over  to  the  information  retrieval 
system.  The  user  generates  a  search  request  about  every  two 
minutes.  Of  all  input  messages,  25. H%  are  search  requests.  The 
data  collected  does  not  measure  the  serial  correlation  between 
search  requests  as  a  part  of  the  input  stream.  With  such 
measurements  and  a  more  detailed  breakdown  of  the  frequencies  of 
various  commands,  all  obtainable  with  some  difficulty  from  the 
available  data,  a  Markov  chain  model  of  the  user  behavior  could 
be  constructed.  In  combination  with  the  guery  structure 
information,  a  number  of  such  user  models  could  generate  standard 
loads  for  benchmark  and  performance  measurement  purposes.  Since 
the  present  work  was  not  directed  in  this  area  the  necessary  work 
was  not  undertaken,  however  it  appears  to  be  an  area  of  interest 
and  potential  worthy  of  further  research. 

The  system  behavior  is  not  as  transportable  as  user  behavior 
but  these  statistics  do  give  some  idea  of  the  level  of  service 
which  can  be  provided  by  an  interactive  information  retrieval 
system  running  on  conventional  hardware.  MEDLINE  service  is 
provided  under  the  TSO  option  of  VS2  on  an  IBM  370/158  at  the 
National  Library  of  Medicine  at  Bethesda,  Maryland.  The  hardware 
for  MEDLINE  is  collectively  known  as  EhtiILL  III  to  distinguish  it 
from  the  hardware  that  runs  MEDLARS,  the  batch  system  from  which 
MEDLINE  grew.  The  MEDLARS  hardware  is  referred  to  as  OPFHILL. 
The  two  systems  share  files  and  offline  searches  for  OPFHILL  can 
be  prepared  and  edited  via  ELHILL.  The  nature  of  any  batch  or 
other  TSO  work  done  on  ELHILL  III  in  competition  with  MEDLINE  is 
unknown  to  this  author. 
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The  average  number  of  HBDLINB  users  daring  the  period  data 
was  collected  vas  8.54.  Because  data  was  only  available  for  a 
single  day  this  and  other  system  statistics  may  be  more 
pathologic  than  previous  statistics.  System  response  time  to  all 
messages  was  3.90  seconds  average,  while  queries  required  11.83 
seconds  on  average.  This  implies  average  response  to  non-search 
input  messages  vas  1.2  5  seconds  average.  To  prevent  overly  long 
searches  monopolizing  the  machine  and  to  allow  users  to  abort 
obviously  faulty  searches,  the  system  queries  the  user  after  his 
search  has  consumed  a  quantum  of  processor  time.  The  user  may 
elect  to  continue  or  abandon  the  search  at  the  end  of  each 
quantum.  Data  indicates  that  searches  take  almost  exactly  one 
quantum  on  average  (1.01)  with  a  standard  deviation  of  1.94. 
That  the  searches  take  an  average  of  one  quantum  is  more  likely  a 
result  of  tuning  the  quantum  size  than  a  manifestation  of  some 
universal  law.  If  we  accept  hear-say  information  that  HBOLIHE 
spends  9  5%  of  its  time  merging,  we  can  conclude  that  a  quantum  is 
roughly  1.4a  seconds,  where  a  is  the  percentage  of  ELHILL  Ill's 
time  devoted  to  MEDLINE.  Thus  an  average  search,  which  consists 
of  6.5  postings  lists  of  601  entries  each  take  roughly  0.5  to  1.5 
seconds  of  370/158  time  to  process  into  a  result  list  of  687 
entries.  The  large  deviation  of  quantum  time  indicates  that 
users  do  pursue  searches  of  up  to  4  quantums  regularly  and  that 
10  or  more  guantum  per  search  occur  about  1%  of  the  time. 

Additional  thought  about  and  study  of  the  data  collected 
here  and  available  in  the  transaction  log  appear  certain  to 
produce  a  better  understanding  of  what  people  do  when  they  use  an 
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information  retrieval  system  and  hov  veil  one  system  does 
information  retrieval.  Benchmarks  and  user  modeling  data  are 
available.  Clues  to  what  is  and  is  not  important  in  an 
information  retrieval  machine  are  available.  A  great  deal 
remains  to  be  discovered  and  explained  about  vhat  we  do  vhen  we 
search  for  answers  in  text. 


Glossary  of  Terms 


logged  in  users:  number  of  usees  actively  connected  to  the 
HEDLINE  subsystem  of  T50. 

search  request: 

search  statement: 

query:  a  syntactially  correct  combination  of  terms  and 

connectives  which  express  the  desired  contents  of 
documents  to  be  retrieved  from  the  data-base. 

search  request  interarrival  time:  time  between  the  arrival  of 
successive  queries  to  MEDLINE. 

real  search  completion  time:  the  real  (wall  clock)  time  between 
the  submission  of  a  query  and  the  result  response* 

search  completion  CPU  time:  the  number  of  time  quantums 
required  to  complete  processing  a  query. 

input  messaqes  per  minute:  the  number  of  messages  from  users 
to  the  system  arriving  at  the  systerr  per  minute. 

output  messages  per  minute:  the  number  of  messages  leaving  the 
system  per  minute  for  all  users. 

system  response  time:  time  from  the  arrival  at  the  system  of  a 
message  from  a  user  to  the  departure  from  the  system 
to  the  user  of  a  reply  message. 

session  time:  time  from  "login"  command  by  user  to  "good-bye" 
message  from  system. 

searches  per  session:  number  of  search  statements  submitted 
by  a  user  in  one  session. 
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input  messages  per  session:  number  of  messages  from  user  to 
HBDLINE  in  one  session. 

output  messages  per  session:  number  of  messages  from  HBDLINE  to 
a  user  in  one  session. 

user  response  time:  time  from  departure  of  message  from  HBDLINE 
to  arrival  of  reply  message  from  user. 

HeSH:  Medical  Subject  Headings,  the  set  of  predetermined 

words  and  phrases  under  which  all  articles  in  HBDLIHE 
are  indexed.  Each  such  word  or  phrase  is  called  an 
index  term.  The  index  terms  are  ordered  in  a  tree 
structure  based  on  specificity.  Bach  index  term  has 
both  a  text  and  a  tree  number  descriptor  which  locates 
it  in  the  hierarchy- 
index  term:  see  HeSH 

normal  term:  one  of  the  index  terms  in  HeSH  or  its  equivalent 
tree  number  descriptor. 

exploded  term:  a  tree  number  descriptor  preceded  by  the  function 
EXPLODE  or  EXP.  Such  a  term  produces  the  or  of  all  its 
basic  terms  as  a  result. 

search  statement  term:  a  term  consisting  of  the  search  statement 
number  of  an  earlier  search.  The  term  represents  the 
results  of  the  earlier  search. 

basic  term:  with  reference  to  the  explode  of  a  tree  number 

descriptor,  that  term  plus  all  terms  below  it  in  the 
tree  structure. 

posting:  pointer  to  a  document  in  the  data  base.  The  postings 
of  a  term  are  all  such  pointers  for  the  term,  they 
collectively  enumerate  the  documents  indexed  by  the 
term. 

terms  per  search  statement:  the  total  number  of  normal, 

exploded,  and  search  statement  terms  in  a  query- 
terms  per  exploded  term:  the  number  of  terms  below  the 
exploded  term  in  the  tree  structure. 

ss  number:  search  statement  number  term. 

connective:  the  logical  operators  used  to  express  relations 
between  terms.  Specifically  AND,  OB,  and  AND  NOT. 

truncated  search:  a  search  statement  whose  length  in 

characters  exceeds  the  size  of  the  message  buffer. 
Truncated  searches  are  not  complete  recordings  of  the 
actual  search  statement  because  only  the  first  57 
or  less  characters  are  stored  in  the  traffic  file. 
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Appendix  8 
DISK/DROH  SIMULATOR 

Three  approachs  are  possible  to  the  study  of  scheduling 
policies  in  an  interactive  information  retrieval  system: 
measurement  on  an  actual  implementation,  simulation  of  an 
implementation,  and  analytic  analysis  of  an  implementation- 
Direct  study  with  an  actual  or  prototype  system  was  simply  not 
feasible  in  terms  of  time,  money,  or  manpower.  Simulation  and 
analytic  studies  are  possible,  each  with  its  own  limitations.  It 
quickly  became  apparent  that  gueueing  theory  was  not  powerful 
enough  to  handle  the  complexity  of  the  problem,  especially  in  the 
area  of  scheduling  disciplines.  Results  obtainable  would  be  a 
function  of  how  cleverly  the  problem  could  be  reshaped  to  fit 
into  known  gueueing  theory  problems.  Generally  such  toying  with 
the  problem  would  reguire  simplifying  assumptions.  Clearly  such 
toying  has  the  potential  to  radically  alter  the  problem.  An 
independent  check  on  the  results  of  such  changes  was  essential 
therefore.  Thus  simulations  are  seen  filling  two  needs  as  an 
adjunct  to  gueueing  theory;  handling  problems  beyond  the  scope 
of  theory  and  providing  an  independent  check  of  approximations 
made  in  the  name  of  theoretic  tractability.  A  third  function  of 
egual  or  greater  importance  was  to  provide  a  quick  check  of  the 
assumption  that  scheduling  did  in  fact  matter.  With  these 
objectives  in  mind  the  design  of  the  simulator  was  begun. 
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Simulations  can  be  divided  into  tvo  classes,  discrete  and 
continuous.  Continuous  systems  are  generally  associated  with 
sets  of  equations  vhich  define  how  conditions  vary  in  time. 
Discrete  systems,  of  which  our  drum/disk  model  is  a  member,  are 
characterized  by  a  pattern  of  events  vhich  occur  in  time.  The 
classic  discrete  event  simulator  example  is  Knuth's  elevator 
simulator  [29],  in  which  events  are  the  arrival  of  a  customer, 
arrival  or  departure  of  the  elevator  to  or  from  a  floor,  etc.  In 
our  problem  the  three  principal  events  are  the  arrival  of  a  bulk 
of  service  requests,  the  arrival  of  the  moving  arm  (in  disk  cases 
only)  at  a  cylinder,  and  the  completion  of  a  record  transfer. 
The  times  at  vhich  these  events  occur  relative  to  each  other  are 
determined  by  probability  distributions  and  the  system's  current 
and  desired  states  via  time-motion  equations.  The  current  state 
is  the  location  of  the  arm  in  terms  of  cylinder  number  and 
rotational  position,  plus  some  possible  scheduling  algorithm 
related  information  such  as  direction  of  arm  motion.  The  desired 
state,  again  in  terms  of  access  mechanism  location,  is  a  function 
of  the  current  state,  the  scheduling  algorithm,  and  the  queue  of 
unfilled  service  requests. 

The  simulation  can  be  driven  in  one  of  two  manners;  either 
time  causes  events  or  events  cause  time.  The  former,  more 
natural  approach  behaves  as  follows:  time  is  advanced  one  unit, 
the  state  of  the  system  is  updated,  and  any  events  scheduled  to 
occur  do  occur.  The  alternate,  and  in  our  case  more  efficient 
method,  is  to  maintain  a  time— ordered  queue  of  future  events.  In 
this  system  time  advances  to  the  next  event,   the   state   of   the 
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system  changes,  and  the  event  causing  the  advance  occurs.  New 
future  events  are  spawned  by  each  event  as  it  becomes  current, 
based  on  the  then  current  state  of  the  system. 

The  question  of  what  language  to  code  the  simulator  in  was 
based  on  the  nature  and  complexity  of  the  general  outline  just 
given.  At  least  three  simulation  languages,  GASP,  GPSS,  and 
Simscript,  are  available  on  the  CSO  360/75.  However,  none  of 
these  are  supported  on  the  370s  in  Chicago  accessible  from 
Urbana.  With  the  heavy  workload  of  the  local  machine,  weak 
support  by  consulting  staff,  and  no  second  source,  they  were 
dropped  as  choices.  The  three  choices  would  then  appear  to  be 
BAL,  FORTRAN,  and  PL/I.  For  speed  in  coding  and  possible 
transportability  to  a  non-IBM  machine,  BAL  was  dropped.  Between 
PL/I  and  FORTRAN  there  were  the  following  considerations:  speed 
of  compilation  and  execution,  optimization  options,  expressive 
power,  and  transportability.  FORTRAN  was  chosen  for  the 
following  reasons:  compilation,  execution,  and  optimization  were 
as  good  or  better  than  PL/I,  recursion  and  block  structure  were 
not  essential  to  the  simulator  coding,  and  only  FORTRAN  was  also 
available  on  the  local  DEC-10  and  PDP-11.  Interactive  checkout 
on  the  DEC-10  and  possible  batch  production  on  our  own  PDP-11 
were  viewed  as  possible  ways  to  save  time  and  money.  Interactive 
debugging  proved  impossible  due  to  the  size  of  test  cases.  Batch 
production  on  the  PDP-11  was  attempted  but  the  360  was  observed 
to  be  12  to  20  times  faster.  The  poor  input/output  facilities  of 
the  PDP-11  would  have  required  transporting  results  to  the  360 
lor   printing,   plotting,  and  storage.   Also  three  hundred  to  six 
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hundred  hours   of   PDP-11   time  vere  simply  not   available  to 
complete  the  required  computations. 

General  Oyer, y.jew  of  Simulator 

The  simulator  system  which  was  developed  consisted  of  the 
simulator  itself,  several  programs  to  maintain  a  dataset  of 
results  stored  on  a  private  disk,  and  printing  and  plotting 
routines  to  assimilate  results  from  the  dataset  for  presentation 
in  printed  or  graphical  form.  The  basic  system  is  depicted  in 
Figure  B. 1.  Parameters  of  the  simulation  cases  to  be  done  are 
submitted  in  card  image.  Results  are  filed  on  the  dataset, 
classified  by  those  parameters.  Management  programs  can 
initialize  the  dataset  or  list  its  index.  A  graphing  program, 
driven  by  data  cards,  can  collect  data  points  from  the  dataset 
based  on  specific  parameter  values  and  produce  nicely  scaled  and 
labeled  plots. 

The  simulator  is  written  in  a  top-down  manner  which  mirrors 
the  logical  structure  at  some  cost  in  efficiency.  Multiple 
labeled  COMMON  areas  are  used  to  collect  in  logically  related 
groups  the  global  variables  of  the  simulation.  Some  of  the 
arrays  logically  belong  to  the  same  data  structure  and  are 
indexed  by  a  common  variable.  Had  the  simulator  been  written  in 
PL/I  these  arrays  would  have  been  an  array  structure  but  due  to 
type  restrictions  in  POBTRAH  multiple  arrays  were  required. 
Extensive  error  and  self-consistence  checking  is  provided,  again 
at   some   cost  in  speed.   Svitchs  in  the  input  parameters  control 
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internal  debugging  aids  which  provide  formatted  listings  of  major 
simulator  tables.  These  svitchs  are  forced  on  in  the  event  of  an 
error  to  provide  maximum  diagonistic  assistance. 

The  main  flaw  of  the  simulator  is  its  inability  to 
discriminate  between  very  large  but  stable  queues  and  truly 
unstable  (growing  without  bound)  queues.  For  simulations  in 
which  the  system  is  near  the  edge  of  saturation  the  stocastic 
nature  of  the  simulator  results  in  some  cases  which  overflow  the 
queue  capacity  of  the  simulator  while  others  don't.  Queue 
capacity  could  have  been  increased  but  the  additional  cost  in 
core  charges  and  the  additional  CPU  time  required  to  overflow  the 
longer  queues  in  truly  unstable  conditions  was  prohibitive. 

The  basic  outline  of  the  operation  of  the  simulator  is  as 
follows: 

1)  read  in  a  count  of  the  number  of  sets  of 
parameters  to  be  processed,  repeat  steps  2  to 
8  that  many  times. 

2)  read  in  a  set  of  parameters  and  do  per 
parameter  set  initialization,  then  repeat 
steps  3  to  5  as  many  times  as  called  for  in 
parameters. 

3)  do  per  case  initialization. 

i»)  simulate  until  the  limit  of  simulated  time 
or  bulk  arrivals  is  reached  or  until  a  queue 
overflows. 

5)  if  simulation  ended  normally,  collect 
statistics  for  this  case. 

6)  combine  results  of  all  normally  terminated 
simulations  to  produce  results  with 
confidence  intervals. 

7)  write  the  results  into  the  dataset  if  file 
switch  is  on. 
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8)  print  results  summary  for  hand  checking  of 
results  for  this  set  of  parameters. 


In  all  the  simulation  consists  of  a  main  program  and  22 
subprograms.  There  are  8  labeled  common  blocks.  The  source  is 
approximately  1375  cards  and  the  resulting  object  module  reguires 
10  2K.  The  simulator  can  perform  approximately  9U0  simulated  drum 
accesses  or  705  simulated  disk  accesses  per  minute  of  IBfl  360/75 
time.  Drum  access  can  be  more  guickly  simulated  because  of  the 
absense  of  arm  motion  simulation. 

1^0  Guide 

The  format  of  the  data  deck  is  one  card  containing  the 
number  of  sets  of  parameters  to  follow  followed  by  that  number  of 
sets  of  three  data  cards. 
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Card  Col.     Contents  (FORMAT) 


First  card 

1-5 

Data  card 

1 

1-10 
11-20 
21-30 
31-40 

Data  card 

2 

1-10 
11-20 
21-30 
31-40 

Data  card 

3 

1-10 

11-20 

21-25 

26-30 

31-35 

number  of  cases  to  follow 

(F10.5) 
(F10.5) 
(F10.5) 
(F10-5) 

algorithm  code  (110) 
number  of  cylinders  (110) 
incremental  seek  time  (F10.5) 
seek  start/stop  time  (F10. 5) 

simulated  time  limit  (F10.5) 
bulk  arrival  count  limit  (110) 
dump  switch,  1  to  dump  tables  (15) 
trace  switch,  1  to  trace  (15) 
histogram  switch,  1  to  print 
histograms  (15) 
36-40     file  switch,  1  to  save  results  on 
the  dataset  (15) 

Data  Card  Formats 
Table  B. 1. 


Data  Structures 

The  data  strucures  which  control  the  operation  of  the 
simulator  are  explained  in  tabular  form  below.  This  information, 
in  conjunction  with  a  listing  of  the  simulator,  should  provide 
sufficient  data  to  allow  a  skilled  programmer  to  modify  the 
simulator- 
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COMMON 


EVENTS 


Array 

(*,2) 
EQ(*,3) 


Osage 

link  to  next  event  (0=end) 

event  code  number 

event  pointer  (obsolete) 

Event  codes: 

1  bulk  arrival 

2  seek  complete 

3  transfer  complete 


DISK 


CLINKS (*,1) 
(♦.2) 
<*,3) 
(♦.4) 
<*,5) 


forvard  cylinder  ordered  list  link 
backward  cylinder  ordered  list  link 
forvard  rotational  ordered  list  link 
backward  rotational  ordered  list  link 
FIPO  forvard  link 


BULKS 


BC0RE(*,1) 
<*,2) 
BC00NT(*,1) 
<*,2) 


total  size  of  bulk  in  core  currently 

total  size  of  bulk  on  disk  currently 

number  of  requests  in  bulk 

number  of  requests  currently  on  disk 


STATST 


SR8(*,1) 
(*,2) 
(*r3) 
(*,<*) 

SR4(*,1) 
(♦.2) 
(*,3) 
(*,<*) 

SI2(*,1) 
<*,2) 

HISTO(*,n) 


sum  of  values  of  a  variable 

sum  of  squares  of  values  of  a  variable 

time  of  last  value  change 

sum  of  time  weighted  values 

histogram  lover  bound 

histogram  increment 

unused 

maximum  value  of  sampled  variable 

maximum  histogram  index 

count  of  sample  values 

count  of  sample  values  in  range 

from  SRU  (*,1)  to 

SR4(*,1)*(SI2(*,1)-1)*SR<*(*,2)  0 
n*1  is  under  range, 
n*SI2(*,1)  is  over  range 

Primary  index  values: 

1  seek  time 

2  seek  distance 

3  rotational  latency 
H   transfer  time 

5  busy  period 

6  idle  period 

7  bulk  service  rate 

8  disk  request  service  rate 

9  core  usage 

COMMON  Data  Structures 
Table  B.2- 
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COMMON    Array  Usage 

SUMARY    ANSW(*,*,1,*)  expected  value 

(*,*,2,*)  standard  deviation 

(*#*#3#*)  maximum  value 

ANS»2(*,1,»)  traffic  intensity 

(*#2,*)  expected  value  of  bulk  service 

queue  length 

(*/3,*)  expected  value  of  request  service 
queue  length 

ANS»I(*,*)  sample  size 

PARM  (*,  1)        -  average  bulk  arrival  rate 
(*#2)        -  average  merge  secvice  rate 

(*,3)  g  -  average  bulk  size 
(*rU)        -  average  record  size 

(*,5)  incremental  cylinder  motion  time 

(*,6)  cylinder  start/stop  time 

{*,!)  unused 

PARMI(*,1)  algorithm  code 

(* ,2)  number  of  cylinders  on  disk 

(*,3)  unused 

First  index:  case  nuir-ber 
Second  index:  as  in  STATST 
Third  index:  1  -  value 

2  -  confidence  interval 


COMMON  Data  Structures 
Table  B. 2  (cont.) . 


Modules 


MAIN:  This  module  implements  the  basic  structure  elaborated 
earlier  by  calls  to  subroutines  and  two  DO  loops.  The 
code  is  short  enough  to  be  self-explanatory. 

INPUT:     This  module  reads  in  the  number  of  parameters  sets  to 
be  expected.  The  variable  CASES  controls  the  outer 
loop  of  the  MAIN  program.  An  EOF  condition  during  the 
READ  in  this  module  terminates  the  simulation  with  an 
approprate  message. 

INIT1:     This  module  initializes  the  variables  in  the  SUMABY 

COMMON,  which  are  used  to  accumulate  the  results  of 

each  trial  of  the  simulation  under  these  parameters  and 
index  them  on  the  dataset. 

INIT2:     This  module  initializes  the  structure  which  contains 
the  driving  information  for  the  simulation.  The  last 
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function  of  INIT1  is  to  schedule  a  bulk  arrival  at 
simulated  time  zero;  this  first  event  will  kick  off 
the  simulation, 

SIMLAT:    This  module  is  the  heart  of  the  simulator.  It  extracts 
the  first  element  in  the  chronologically  ordered  queue 
of  events,  sets  the  time  to  the  time  of  that  event,  and 
calls  one  of  three  routines  to  accomplish  the  current 
event.  This  action  is  repeated  in  a  loop  until  the 
desired  number  of  simulated  bulks  have  arrived,  a 
limit  in  simulated  time  is  exceeded,  or  one  of  the 
queues  overflows.  This  last  condition  is  signalled 
back  to  this  level  by  setting  the  LOGICAL  variable 
ABORT  to  .TRUE.  .  simlat  returns  only  after 
it  exits  its  loop  for  one  of  these  three  reasons. 

BESLT1:    This  routine  processes  all  the  data  collected  during 
repeated  simulations  under  the  same  conditions  to 
produce  confidence  intervals  at  the  95*  level  for  most 
measured  results. 


RESLT2: 


FILEIT: 


DONE: 


DCNE2: 


DOHPS 


This  routine  adds  the  results  of  one  simulation  to 
previous  results  of  other  simulations  made  under  the 
same  conditions.  By  accumulating  the  value  of  each 
measurement  and  its  square,  along  vith  a  count  of  the 
number  of  simulations,  RESLT2  provides  RESLT1 
the  data  it  needs  to  make  its  computations. 


This  routine  manipulates  two  datase 
directory  and  accumulated  results  f 
performed.  Directory  entries  consis 
parameters  of  the  simulation.  A  nev 
to  the  directory  when  no  current  en 
old  entry  vhich  matches  a  nev  resul 
the  nev  result.  All  entries  have  a 
they  were  made.  Each  directory  entr 
in  the  second  dataset  which  contain 
and  histograms  gathered  in  the  asso 


ts  vhich  contain  a 
rom  all  simulations 
t  of  all  the 
entry  is  added 
try  matchs.  An 
t  is  replaced  by 
time  and  date  when 
y  points  to  a  region 
s  all  the  statistics 
ciated  simulations. 


This  module  calls  D0NE2  and  then  terminates  the 
run.  It  is  called  when  an  error  makes  continuation 
impossible. 

This  module  prints  a  summary  of  the  results  of  a  group 
of  simulations.  Results  vhich  may  be  questionable  due 
to  table  overflow  in  the  simulator  are  flagged. 

This  module  prints  out  in  easy  to  read  format  the 
contents  of  the  used  regions  of  EVENTS,  DISK,  and 
BOLKS  common  areas.  These  three  areas  contain  all 
the  information  necessary  to  understand  the  state-  of 
the  simulator  at  the  time  DOHPS  was  called.  This 
module  is  generally  called  by  any  abnormal  termination 
of  the  simulation. 
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BOLKIN: 


SEEKDN: 


READDN: 


NXTREQ: 


QEVENT: 


SETSTS 


ISTATS 


STATS: 


QSTATS 


This  module 
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random  numbe 
of  the  bulk 
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generator,  a 
random  chara 
COMHON  areas 
the  balk's  a 
a  service  re 


performs  the  bookkeepin 
requests  arrives  at  the 
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and  CDP  functions  and  a 
random  number  of  servi 
cteristics  are  added  to 
.  If  the  DISK  gueue  was 
rrival,  NXTBBQ  is  calle 
quest  to  be  selected  an 


g  necessary  when  a 
system.  Using  a 

an  inverse  CDF 

he  next  bulk  arrival 

QEVENT.  Osing 
random  number 

ce  requests  with 
the  DISK  and  BULKIM 
empty  previous  to 

d  directly  to  cause 

d  scheduled. 


This  module  collects  seek  activity  statistics  and  then 
calls  NXTBEQ  to  select  and  schedule  a  service  request. 

This  module  collects  statistics  on  record  transfers, 
removes  the  nov  completed  service  request  from  the  DISK 
data  structure,  and  accumulates  bulk  statistics.  If  the 
service  request  just  finished  was  the  last  of  its  bulk 
it  also  removes  the  bulk  from  the  BOLKS  data  structure. 
It  then  calls  NXTBEQ  to  select  and  schedule  the  next 
service  request. 

This  module  contains  the  logic  to  select  from  the 
available  requests  in  DISK  the  next  request  to  be 
serviced  by  any  one  of  five  policies.  The  policy  used 
is  selected  by  an  input  parameter.  Eased  on  the  request 
selected,  NXTBBQ  schedules  either  a  seek  or  read,  as 
needed,  using  QEVENT. 

This  routine  places  an  event  in  the  chronologically 
ordered  list  of  future  events.  Each  event  is 
characterized  by  the  time  at  which  it  is  to  occur  and 
an  event  code  which  represents  what  is  to  occur.  Each 
event  code  has  an  associated  event  routine  to  process 
the  event  when  SIHLAT  selects  it  as  the  current  event. 
The  three  event  routines  are  BULKIN,  SEEKDN,  and 
BEADDN. 

This  routine  initializes  a  statistics  area  for  a  given 
statistic.  It  initializes  variables  and  determines 
bounds  for  histogram  arrays. 

This  routine  is  an  INTEGEB  entry  to  the  STATS 
routine. 

This  routine  adds  a  sample  point  to  a  statistics  area. 
It  accumulates  the  powers  necessary  to  later  compute 
mean  and  variance,  it  keeps  running  minimum  and 
maximum  values  of  the  statistic,  and  it  adds  an  entry 
to  the  histogram  for  the  value  of  the  statistic. 

This  routine  collects  additional  information  on 
statistics  which  are  queues,  to  enable  later 
computations  of  mean  queue  lengths. 
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CORSST:    This  routine  accumulates  statistics  on  simulated 

buffer  storage  usage  in  a  manner  similar  to  STATS. 

RAND:  This  routine  generates  a  uniformly  distributed 
continuous  random  number  between  the  bounds  it 
vas  called  with. 

IRAND:  This  routine  generates  a  uniformly  distributed  discrete 
random  varable  with  an  integer  value  between  the  bounds 
it  was  called  with. 

RAN3Z:    This  routine  is  a  CSO  supplied  random  number  generator 
which  provides  uniform  pseudo-random  numbers  between 
zero  and  one.  It  replaced  two  other  random  number 
generators  which  proved  to  have  severe  problems  in  the 
current  context.  The  IBH  SSP  package  generator  vas 
observed  to  produce  strongly  correlated  results  over  a 
lag  of  three.  Since  three  calls  were  made  to  the 
generator  for  each  service  reguest  generated  by  bulkin, 
this  produced  a  severe  anomaly  in  FIPO  simulation 
results  which  resulted  in  its  detection.  Simulation 
results  for  FIFO  using  BAM3Z  are  in  close  agreement 
with  analytical  predictions  and  on  that  basic  and  its 
overall  well  known  behavior  it  vas  selected. 


Other  Programs 

INIT:     This  program  creates  the  datasets  required  to 

accumulate  results  from  the  simulator.  The  directory, 
with  room  for  2500  simulation  result  sets,  is  zeroed. 

LIST:     A  listing  of  the  directory  for  the  simulation  dataset 
is  produced  by  this  program.  The  disk  index,  time  and 
date  of  creation,  and  the  parameters  for  each 
simulation  result  set  are  listed. 

PLOT:     In  response  to  control  cards  this  program  collects, 
sorts,  scales,  graphs,  and  labels  data  from  the 
dataset.  The  data  to  be  plotted,  the  axis  labels, 
graph  labels,  and  axis  lengths  and  scales  can  be 
specified  or  program  defaults  will  be  used. 

COHPND:    This  program  lists  the  complete  contents  of  the 
simulator  results  dataset  with  a  sorted  table  of 
contents.  Each  simulation  set  contains  not  only 
all  the  parameters  and  statistics  but  also  histogram 
counts  for  most  statistics.  The  resulting  listing  is 
2430  pages  at  present.  The  results  form  the  reference 
when  checking  becomes  necessary  in  analytic  work. 
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Source  for  all  the  programs  described  above,  along  vith 
sample  JCL  and  data  are  available  from  the  author.  Any  and  all 
errors  in  the  programs  or  this  description  are  the  responsibility 
of  the  author* 
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APPENDIX  C 
ALGORITHM  COMPARISON  TABLES 

This  appendix  contains  comparison  tables  for  the  five 
scheduling  algorithms  considered  in  this  thesis.  Along  with 
Tables  3.3a-3.5b  they  provide  uniformly  weighted  comparisons  for 
reguest  service  time,  bulk  service  time,  and  core  usage  summed 
over  all  reasonable  combinations  of  {,  g  and  i.  They  can  be  used 
to  study  the  net  effect  of  any  of  the  three  parameters,  singlely 
or  in  pairs,  on  the  three  measures.  Cetails  of  their 
construction  and  use  are  found  in  the  concluding  section  of 
Chapter  3. 
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Table  C. 1a. 
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Table  C.1a  (cont. ). 
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Table  C.1a  (cont.). 
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Table  C.1a  (cont.) . 
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Table  C.  1b. 
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39 

24 

PSBP 

13 

23 

PSBP 

32 

23 

PSBF 

20 

23 

Disk 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=0.50 

FIFO 

0 

24 

FIFO 

0 

24 

FIFO 

5 

24 

g=10 

MSCAN 

29 

24 

MSCAN 

22 

24 

MSCAN 

39 

24 

i=  * 

SCAN 

45 

24 

SCAN 

20 

24 

SCAN 

11 

24 

SBP 

29 

24 

SBF 

35 

24 

SBF 

39 

24 

PSBP 

17 

24 

PSBF 

43 

24 

PSBF 

26 

24 

Disk 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=0.50 

FIFO 

0 

24 

FIFO 

0 

24 

FIFO 

2 

24 

g=20 

MSCAN 

28 

24 

MSCAN 

25 

24 

MSCAN 

38 

24 

i=  * 

SCAN 

45 

24 

SCAN 

20 

24 

SCAN 

14 

24 

SBF 

28 

24 

SBF 

32 

24 

SBF 

38 

24 

PSBP 

19 

24 

PSBP 

43 

24 

PSBF 

28 

24 

Disk 

Request 

Service 

Bulk 

Service 

Core 

Osage 

6=0.50 

FIFO 

0 

23 

FIFO 

0 

23 

FIFO 

1 

23 

g=50 

MSCAN 

28 

24 

MSCAN 

28 

24 

MSCAN 

36 

24 

i=  * 

SCAN 

48 

24 

SCAN 

18 

2<4 

SCAN 

16 

24 

SBF 

28 

24 

SBF 

34 

24 

SBP 

39 

24 

PSBP 

14 

23 

PSBF 

38 

23 

PSBF 

26 

23 

Disk  Performance  Comparisons  Summing  over  i 
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Disk 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=1.00 

FIFO 

0 

17 

FIFO 

0 

17 

FIFO 

17 

17 

g=  2 

MSCAN 

20 

17 

MSCAN 

14 

17 

HSCAN 

24 

17 

i=  * 

SCAN 

37 

20 

SCAN 

29 

20 

SCAN 

15 

20 

SBF 

20 

17 

SBF 

22 

17 

SBF 

24 

17 

PSBF 

11 

17 

PSBF 

23 

17 

PSBF 

8 

17 

Disk 

Request 

Service 

Bulk 

Service 

Core 

Osage 

6=1.00 

PIFO 

0 

17 

FIFO 

0 

17 

FIFO 

9 

17 

g=  5 

MSCAN 

19 

17 

MSCAN 

15 

17 

HSCAN 

26 

17 

i=  * 

SCAN 

40 

20 

SCAN 

22 

20 

SCAN 

14 

20 

SBF 

19 

17 

SBF 

23 

17 

SBF 

26 

17 

PSBF 

10 

17 

PSBF 

28 

17 

PSBF 

13 

17 

Disk 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=1.00 

FIFO 

0 

21 

FIFO 

0 

21 

FIFO 

7 

21 

g=10 

HSCAN 

25 

21 

MSCAN 

19 

21 

HSCAN 

33 

21 

i=  * 

SCAN 

46 

24 

SCAN 

23 

24 

SCAN 

16 

24 

SBF 

25 

21 

SBF 

30 

21 

SBF 

33 

21 

PSBF 

12 

21 

PSBF 

36 

21 

PSBF 

19 

21 

Disk 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=1.00 

FIFO 

0 

21 

FIFO 

0 

21 

FIFO 

5 

21 

g=20 

MSCAN 

23 

21 

MSCAN 

22 

21 

HSCAN 

31 

21 

i-  * 

SCAN 

45 

24 

SCAN 

23 

24 

SCAN 

18 

24 

SBF 

23 

21 

SBF 

27 

21 

SBF 

31 

21 

PSBF 

17 

21 

PSBF 

36 

21 

PSBF 

23 

21 

Disk 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=1.00 

FIFO 

0 

15 

FIFO 

0 

15 

FIFO 

1 

15 

g=50 

MSCAN 

18 

16 

HSCAN 

20 

16 

MSCAN 

27 

16 

i=  * 

SCAN 

32 

16 

SCAN 

11 

16 

SCAN 

12 

16 

SBF 

13 

15 

SBF 

15 

15 

SBF 

19 

15 

PSBF 

15 

16 

PSBF 

32 

16 

PSBF 

19 

16 

Disk  Performance  Comparisons  Summing  over  i 
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Disk 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=2.00 

FIFO 

0 

12 

FIFO 

2 

12 

FIFO 

16 

12 

g=  2 

HSCAN 

13 

12 

HSCAN 

8 

12 

HSCAN 

17 

12 

i=  * 

SCAN 

21 

12 

SCAN 

14 

12 

SCAN 

3 

12 

SBF 

13 

12 

SBF 

16 

12 

SBF 

17 

12 

PSBF 

13 

12 

PSBF 

20 

12 

PSBF 

7 

12 

Disk 

Request 

Serv 

ice 

Bulk 

Service 

Core 

Usage 

6=2.00 

FIFO 

0 

12 

FIFO 

0 

12 

FIFO 

9 

12 

g=  5 

HSCAN 

13 

12 

HSCAN 

11 

12 

HSCAN 

20 

12 

i=  * 

SCAN 

24 

12 

SCAN 

10 

12 

SCAN 

2 

12 

SBF 

13 

12 

SBF 

18 

12 

SBF 

20 

12 

PSBF 

10 

12 

PSBF 

21 

12 

PSBF 

9 

12 

Disk 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=2.00 

PIFO 

0 

13 

FIFO 

0 

13 

FIFO 

8 

13 

g=10 

HSCAN 

15 

13 

HSCAN 

12 

13 

HSCAN 

20 

13 

i=  * 

SCAN 

30 

16 

SCAN 

16 

16 

SCAN 

10 

16 

SBF 

14 

13 

SBF 

18 

13 

SBF 

20 

13 

PSBF 

9 

13 

PSBF 

22 

13 

PSBF 

10 

13 

Disk 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=2.00 

PIFO 

0 

13 

FIFO 

0 

13 

FIFO 

8 

13 

g=20 

HSCAN 

14 

13 

HSCAN 

13 

13 

HSCAN 

16 

13 

i=  * 

SCAN 

29 

16 

SCAN 

17 

16 

SCAN 

13 

16 

SBF 

13 

13 

SBF 

15 

13 

SBF 

16 

13 

PSBF 

12 

13 

PSBF 

23 

13 

PSBF 

15 

13 

Disk 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=2.00 

FIFO 

0 

11 

FIFO 

0 

1  1 

FIFO 

3 

11 

g=50 

HSCAN 

8 

11 

HSCAN 

10 

11 

HSCAN 

13 

11 

i=  * 

SCAN 

24 

12 

SCAN 

8 

12 

SCAN 

7 

12 

SBF 

13 

12 

SBF 

16 

12 

SBF 

21 

12 

PSBF 

13 

12 

PSBF 

24 

12 

PSBF 

14 

12 

Disk  Performance  Comparisons  Summing  over  i 
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Drum 

Request 

Service 

Bulk 

Service 

Core 

Osage 

6=0.25 

FIFO 

0 

20 

FIFO 

0 

20 

FIFO 

4 

20 

g=  * 

MSCAN 

25 

20 

MSCAN 

25 

20 

MSCAN 

24 

20 

i=.05 

SCAN 

25 

20 

SCAN 

25 

20 

SCAN 

24 

20 

SBF 

25 

20 

SBF 

25 

20 

SBF 

24 

20 

PSBF 

25 

20 

PSBF 

25 

20 

PSBF 

24 

20 

Drum 

Request 

Service 

Bulk 

Service 

Core 

Osage 

6=0.25 

FIFO 

0 

20 

FIFO 

0 

20 

FIFO 

2 

20 

g=  * 

MSCAN 

22 

20 

MSCAN 

24 

20 

MSCAN 

25 

20 

i=.15 

SCAN 

34 

20 

SCAN 

25 

20 

SCAN 

24 

20 

SBF 

22 

20 

SBF 

25 

20 

SBF 

25 

20 

PSBF 

22 

20 

PSBF 

26 

20 

PSBF 

24 

20 

Drum 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=0-25 

FIFO 

0 

20 

FIFO 

0 

20 

FIFO 

4 

20 

g=  * 

MSCAN 

21 

20 

MSCAN 

23 

20 

MSCAN 

29 

20 

i=.2  5 

SCAN 

38 

20 

SCAN 

23 

20 

SCAN 

16 

20 

SBF 

21 

20 

SBF 

26 

20 

SBF 

29 

20 

PSBF 

20 

20 

PSBF 

28 

20 

PSBF 

22 

20 

Drum 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=0.25 

FIFO 

0 

20 

FIFO 

0 

20 

FIFO 

5 

20 

g=  * 

MSCAN 

20 

20 

MSCAN 

23 

20 

MSCAN 

29 

20 

i=-35 

SCAN 

40 

20 

SCAN 

23 

20 

SCAN 

13 

20 

SBF 

20 

20 

SBF 

23 

20 

SBF 

29 

20 

PSBF 

20 

20 

PSBF 

31 

20 

PSBF 

24 

20 

Drum 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=0.25 

FIFO 

0 

20 

FIFO 

0 

20 

FIFO 

3 

20 

g=  * 

MSCAN 

20 

20 

MSCAN 

21 

20 

MSCAN 

31 

20 

i=.45 

SCAN 

40 

20 

SCAN 

22 

2C 

SCAN 

10 

20 

SBF 

20 

20 

SBF 

22 

20 

SBF 

31 

20 

PSBF 

20 

20 

PSBF 

35 

20 

PSBF 

25 

20 

Drum 

Request 

Service 

Bulk 

Service 

Core 

Osage 

6=0.25 

FIFO 

0 

20 

FIFO 

0 

20 

FIFO 

7 

20 

g=  ♦ 

MSCAN 

20 

20 

MSCAN 

20 

20 

MSCAN 

30 

20 

i=.55 

SCAN 

40 

20 

SCAN 

22 

20 

SCAN 

7 

20 

SBF 

20 

20 

SBF 

21 

20 

SBF 

30 

20 

PSBF 

20 

20 

PSBF 

37 

20 

PSBF 

26 

20 

Drum  Performance  Comparisons  Summing  over  g 
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Drum 

Bequest 

Service 

Bulk 

Service 

Core 

Usaqe 

6=0.50 

FIFO 

0 

20 

PIFO 

0 

20 

FIPO 

4 

20 

g=  * 

HSCAN 

25 

20 

MSCAN 

25 

20 

MSCAN 

24 

20 

i=-05 

SCAN 

25 

20 

SCAN 

25 

20 

SCAN 

24 

20 

SBP 

25 

20 

SBP 

25 

20 

SBF 

24 

20 

PSBF 

25 

20 

PSBP 

25 

20 

PSBF 

24 

20 

Drum 

Request 

Serv 

ice 

Bulk 

Service 

Core 

Usaqe 

6=0.50 

PIFO 

0 

20 

FIFO 

0 

20 

PIFO 

5 

20 

g=  * 

MSCAN 

22 

20 

MSCAN 

24 

20 

MSCAN 

27 

20 

i=.  15 

SCAN 

34 

20 

SCAN 

20 

20 

SCAN 

16 

20 

SBP 

22 

20 

SBP 

25 

20 

SBF 

27 

20 

PSBP 

22 

20 

PSBP 

31 

20 

PSBP 

25 

20 

Drum 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=0.50 

PIPO 

0 

20 

PIFO 

0 

20 

PIFO 

7 

20 

g=  * 

MSCAN 

20 

20 

MSCAN 

22 

20 

MSCAN 

30 

20 

i=.25 

SCAN 

39 

20 

SCAN 

19 

20 

SCAN 

8 

20 

SBP 

20 

20 

SBF 

24 

20 

SBF 

30 

20 

PSBP 

21 

20 

PSBP 

35 

20 

PSBF 

25 

20 

Drum 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=0.50 

FIPO 

0 

20 

FIFO 

0 

20 

FIFO 

11 

20 

g=  * 

MSCAN 

20 

20 

MSCAN 

21 

20 

MSCAN 

30 

20 

i=.35 

SCAN 

40 

20 

SCAN 

17 

20 

SCAN 

4 

20 

SBP 

20 

20 

SBF 

23 

20 

SBF 

30 

20 

PSBF 

20 

20 

PSBF 

39 

20 

PSBF 

25 

20 

Drum 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=0.50 

FIFO 

0 

20 

FIFO 

0 

20 

FIFO 

13 

20 

g=  * 

MSCAN 

20 

20 

MSCAN 

21 

20 

MSCAN 

32 

20 

i=.4  5 

SCAN 

40 

20 

SCAN 

17 

20 

SCAN 

2 

20 

SBP 

20 

20 

SBF 

23 

20 

SBF 

32 

20 

PSBF 

20 

20 

PSBF 

39 

20 

PSBP 

21 

20 

Drum 

Request 

Service 

Bulk 

Service 

Core 

Usaqe 

6=0.50 

FIFO 

0 

20 

FIFO 

0 

20 

FIFO 

14 

20 

g=  * 

MSCAN 

20 

20 

MSCAN 

21 

20 

HSCAN 

33 

20 

i=-55 

SCAN 

40 

20 

SCAN 

17 

20 

SCAN 

2 

20 

SBF 

20 

20 

SBF 

24 

20 

SBF 

33 

20 

PSBF 

20 

20 

PSBF 

38 

20 

PSBF 

18 

20 

Drum  Performance  Comparisons  Summing  over  g 
Table  C.2a  (cont.) . 


173 


Drum 

Reguest 

Service 

Bulk 

Service 

Core 

Usage 

6=1.00 

FIPO 

0 

20 

FIFO 

0 

20 

FIFO 

8 

20 

g=  * 

MSCAN 

25 

20 

MSCAN 

26 

20 

MSCAN 

24 

20 

i=.05 

SCAN 

25 

20 

SCAN 

22 

20 

SCAN 

21 

20 

SBF 

25 

20 

SBF 

26 

20 

SBF 

24 

20 

PSBP 

25 

20 

PSBF 

26 

20 

PSBF 

23 

20 

Drum 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=1.00 

FIFO 

0 

20 

FIFO 

0 

20 

FIFO 

10 

20 

g*  * 

MSCAN 

21 

20 

MSCAN 

23 

20 

MSCAN 

29 

20 

i=-15 

SCAN 

37 

20 

SCAN 

16 

20 

SCAN 

5 

20 

SBF 

21 

20 

SBF 

24 

20 

SBF 

29 

20 

PSBF 

21 

20 

PSBF 

37 

20 

PSBF 

27 

20 

Drum 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=1.00 

FIFO 

0 

20 

FIFO 

0 

2  0 

FIFO 

16 

20 

g=  * 

MSCAN 

20 

20 

MSCAN 

23 

20 

MSCAN 

32 

20 

i=-25 

SCAN 

39 

20 

SCAN 

13 

20 

SCAN 

1 

20 

SBF 

21 

20 

SBF 

24 

20 

SBF 

32 

20 

PSBF 

20 

20 

PSBF 

40 

20 

PSBF 

19 

20 

Drum 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=1.00 

FIFO 

0 

20 

FIFO 

0 

20 

FIFO 

17 

20 

g=  * 

MSCAN 

20 

20 

MSCAN 

22 

20 

MSCAN 

33 

20 

i=.35 

SCAN 

UO 

20 

SCAN 

13 

20 

SCAM 

0 

20 

SBF 

20 

20 

SBF 

26 

20 

SBF 

33 

20 

PSBF 

20 

20 

PSBF 

39 

20 

PSBF 

17 

20 

Drum 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=1.00 

FIFO 

0 

20 

FIFO 

0 

20 

FIFO 

18 

20 

g=  * 

MSCAN 

20 

20 

MSCAN 

20 

20 

MSCAN 

34 

20 

i=-45 

SCAN 

40 

20 

SCAN 

13 

20 

SCAN 

0 

20 

SBF 

20 

20 

SBF 

28 

20 

SBF 

34 

20 

PSBF 

20 

20 

PSBF 

39 

20 

PSBF 

14 

20 

Drum 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=1.00 

FIFO 

0 

20 

FIFO 

0 

20 

FIFO 

19 

20 

g=  * 

MSCAN 

21 

20 

MSCAN 

16 

20 

MSCAN 

32 

20 

i=.55 

SCAN 

UO 

20 

SCAN 

16 

20 

SCAN 

2 

20 

SBF 

21 

20 

SBF 

30 

20 

SBF 

33 

20 

PSBF 

18 

20 

PSBF 

38 

20 

PSBF 

14 

20 

Drum  Performance  Comparisons  Summing  over  g 
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Drum 

Request 

Service 

Bulk 

Service 

Core 

Osage 

6=2.00 

FIFO 

0 

20 

FIFO 

0 

20 

FIFO 

17 

20 

g  =  * 

MSCAN 

25 

20 

MSCAN 

25 

20 

MSCAN 

24 

20 

i=.05 

SCAN 

25 

20 

SCAN 

18 

20 

SCAN 

12 

20 

SBF 

25 

20 

SBF 

27 

20 

SBF 

24 

20 

PSBF 

25 

20 

PSBF 

30 

20 

PSBF 

23 

20 

Drum 

Request 

Service 

Bulk 

Service 

Core 

Osage 

6=2.00 

FIFO 

0 

20 

FIFO 

5 

20 

FIFO 

23 

20 

g=  * 

MSCAN 

21 

20 

MSCAN 

23 

20 

MSCAN 

29 

20 

i=.  15 

SCAN 

37 

20 

SCAN 

8 

20 

SCAN 

0 

20 

SBF 

21 

20 

SBF 

24 

20 

SBF 

29 

20 

PSBF 

21 

20 

PSBF 

40 

20 

PSBF 

19 

20 

Drum 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=2.00 

FIFO 

0 

20 

FIFO 

7 

20 

FIFO 

25 

20 

g*  * 

MSCAN 

20 

20 

MSCAN 

17 

20 

MSCAN 

30 

20 

i=.25 

SCAN 

40 

20 

SCAN 

7 

20 

SCAN 

0 

20 

SBF 

20 

20 

SBF 

30 

20 

SBF 

30 

20 

PSBF 

20 

20 

PSBF 

39 

20 

PSBF 

15 

20 

Drum 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=2.00 

FIFO 

0 

18 

FIFO 

5 

18 

FIFO 

22 

18 

g=  * 

MSCAN 

16 

18 

MSCAN 

10 

18 

MSCA1 

25 

18 

i=.35 

SCAN 

40 

20 

SCAN 

15 

20 

SCAN 

6 

20 

SBF 

22 

20 

SBF 

35 

20 

SBF 

33 

20 

PSBF 

16 

18 

PSBF 

29 

18 

PSBF 

8 

18 

Drum 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=2.00 

FIFO 

0 

10 

FIFO 

0 

10 

FIFO 

0 

10 

g=  * 

MSCAN 

6 

10 

MSCAN 

7 

10 

MSCAN 

14 

10 

i=.45 

SCAN 

32 

16 

SCAN 

21 

16 

SCAN 

20 

16 

SBF 

8 

10 

SBF 

14 

10 

SBF 

14 

10 

PSBF 

8 

10 

PSBF 

14 

10 

PSBF 

8 

10 

Drum 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=2.00 

FIFO 

0 

0 

FIFO 

0 

0 

FIFO 

0 

0 

g=  * 

MSCAN 

0 

0 

MSCAN 

0 

0 

MSCAN 

0 

0 

i=.55 

SCAN 

0 

0 

SCAN 

0 

0 

SCAN 

0 

0 

SBF 

0 

0 

SBF 

0 

0 

SBF 

0 

0 

PSBF 

0 

0 

PSBF 

0 

0 

PSBF 

0 

0 

Drum  Performance  Comparisons  Summing  over 
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Disk 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=0.25 

PIFO 

0 

20 

FIFO 

0 

20 

FIFO 

1 

20 

9«  * 

MSCAN 

25 

20 

MSCAN 

25 

20 

MSCAN 

25 

20 

i=.05 

SCAN 

25 

20 

SCAN 

25 

20 

SCAN 

25 

20 

SBP 

25 

20 

SBF 

25 

20 

SBF 

25 

20 

PSBF 

25 

20 

PSBF 

25 

20 

PSBF 

24 

20 

Disk 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=0.25 

FIPO 

0 

20 

FIFO 

0 

20 

FIFO 

2 

20 

g-  * 

MSCAN 

22 

20 

MSCAN 

23 

20 

MSCAN 

30 

20 

i=.  15 

SCAN 

UO 

20 

SCAN 

19 

20 

SCAN 

16 

20 

SBF 

22 

20 

SBF 

26 

20 

SBF 

30 

20 

PSBF 

16 

20 

PSBF 

32 

20 

PSBF 

22 

20 

Disk 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=0.25 

FIFO 

0 

20 

FIFO 

0 

20 

FIFO 

5 

20 

g=  * 

MSCAN 

24 

20 

MSCAN 

21 

20 

MSCAN 

33 

20 

i=.25 

SCAN 

UO 

20 

SCAN 

19 

20 

SCAN 

9 

20 

SBF 

24 

20 

SBF 

25 

20 

SBF 

33 

20 

PSBF 

12 

20 

PSBF 

35 

20 

PSBF 

20 

20 

Disk 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=0.25 

FIFO 

0 

20 

FIFO 

0 

20 

FIFO 

9 

20 

g=  * 

MSCAN 

24 

20 

MSCAN 

19 

20 

MSCAN 

34 

20 

i=-35 

SCAN 

40 

20 

SCAN 

20 

20 

SCAN 

5 

20 

SBF 

24 

20 

SBF 

26 

20 

SBF 

34 

20 

PSBF 

12 

20 

PSBF 

35 

20 

PSBF 

18 

20 

Disk 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=0.25 

FIFO 

0 

20 

FIFO 

0 

20 

FIFO 

11 

20 

g=  * 

MSCAN 

25 

20 

MSCAN 

17 

20 

MSCAN 

35 

20 

i=.45 

SCAN 

40 

20 

SCAN 

20 

20 

SCAN 

4 

20 

SBF 

25 

20 

SBF 

29 

20 

SBF 

35 

20 

PSBF 

10 

20 

PSBF 

34 

20 

PSBF 

15 

20 

Disk 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=0.25 

FIFO 

0 

19 

FIFO 

0 

19 

FIFO 

0 

19 

g=  * 

MSCAN 

25 

20 

MSCAN 

17 

20 

MSCAN 

35 

20 

i=.55 

SCAN 

40 

20 

SCAN 

23 

20 

SCAN 

12 

20 

SBF 

25 

20 

SBF 

30 

20 

SBF 

35 

20 

PSBF 

8 

19 

PSBF 

28 

19 

PSBF 

16 

19 

Disk  Performance  Comparisons  Summing  over  g 
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Disk 

Reguest 

Service 

Bulk 

Service 

Core 

Usage 

6=0.50 

FIPO 

0 

20 

FIFO 

0 

20 

PIFO 

2 

20 

g=  * 

HSCAN 

24 

20 

MSCAN 

25 

20 

HSCAN 

25 

20 

i=.05 

SCAN 

28 

20 

SCAN 

24 

20 

SCAN 

24 

20 

SBP 

24 

20 

SBF 

25 

20 

SBP 

25 

20 

PSBP 

24 

20 

PSBP 

26 

20 

PSBP 

24 

20 

Disk 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=0.50 

PIPO 

0 

20 

PIFO 

0 

20 

PIPO 

4 

20 

g=  * 

HSCAN 

21 

20 

MSCAN 

23 

20 

HSCAN 

31 

20 

i=.15 

SCAN 

40 

20 

SCAN 

17 

20 

SCAN 

10 

20 

SBF 

22 

20 

SBP 

25 

20 

SBP 

31 

20 

PSBP 

17 

20 

PSBF 

35 

20 

PSBF 

24 

20 

Disk 

Request 

Service 

Bulk 

Service 

Core 

Osage 

6=0.50 

FIFO 

0 

20 

PIFO 

0 

20 

FIPO 

9 

20 

g=  * 

MSCAN 

24 

20 

MSCAN 

21 

20 

HSCAN 

33 

20 

i=.25 

SCAN 

40 

20 

SCAN 

17 

20 

SCAN 

5 

20 

SBF 

24 

20 

SBF 

26 

20 

SBP 

33 

20 

PSBP 

12 

20 

PSBF 

36 

20 

PSBP 

20 

20 

Disk 

Request 

Service 

Bulk 

Service 

Core 

Osaqe 

6=0.50 

PIFO 

0 

20 

FIPO 

0 

20 

PIPO 

11 

20 

g=  * 

MSCAN 

25 

20 

MSCAN 

17 

20 

HSCAN 

35 

20 

i=.35 

SCAN 

40 

20 

SCAN 

19 

20 

SCAN 

4 

20 

SBF 

25 

20 

SBF 

29 

20 

SBP 

35 

20 

PSBP 

10 

20 

PSBF 

35 

20 

PSBP 

15 

20 

Disk 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=0.50 

FIFO 

0 

20 

PIFO 

0 

20 

FIFO 

0 

20 

g=  ♦ 

MSCAN 

25 

20 

MSCAN 

16 

20 

HSCAN 

34 

20 

i=.45 

SCAN 

40 

20 

SCAN 

21 

20 

SCAN 

11 

20 

SBF 

25 

20 

SBF 

31 

20 

SBP 

35 

20 

PSBP 

10 

20 

PSBF 

32 

20 

PSBP 

20 

20 

Disk 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=0.50 

PIFO 

0 

15 

FIFO 

0 

15 

FIPO 

0 

15 

g=  ♦ 

MSCAN 

20 

17 

MSCAN 

17 

17 

HSCAN 

27 

17 

i=.55 

SCAN 

40 

20 

SCAN 

25 

20 

SCAN 

20 

20 

SBF 

20 

17 

SBF 

28 

17 

SBF 

29 

17 

PSBP 

4 

15 

PSBF 

14 

15 

PSBF 

8 

15 

Disk  Performance  Comparisons  Summing  over 
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Disk 

Request 

Service 

Bulk 

Service 

Core 

Osage 

6=1.00 

PIFO 

0 

20 

FIFO 

0 

20 

FIFO 

3 

20 

g«  * 

MSCAN 

23 

20 

MSCAN 

24 

20 

MSCAN 

24 

20 

i=.05 

SCAN 

32 

20 

SCAN 

21 

20 

SCAN 

24 

20 

SBF 

23 

20 

SBF 

25 

20 

SBF 

25 

20 

PSBF 

22 

20 

PSBF 

30 

20 

PSBF 

24 

20 

Disk 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=1.00 

FIPO 

0 

20 

FIFO 

0 

20 

FIFO 

10 

20 

g-  * 

MSCAN 

23 

20 

MSCAN 

22 

20 

MSCAN 

33 

20 

i=-15 

SCAN 

40 

20 

SCAN 

15 

20 

SCAN 

6 

20 

SBF 

23 

20 

SBF 

25 

20 

SBF 

33 

20 

PSBF 

14 

20 

PSBF 

38 

20 

PSBF 

18 

20 

Disk 

Request 

Service 

Bulk 

Service 

Core 

Osage 

6=1.00 

FIPO 

0 

20 

FIFO 

0 

2  0 

FIFO 

12 

20 

g=  * 

MSCAN 

24 

20 

MSCAN 

19 

20 

MSCAN 

34 

20 

i=.25 

SCAN 

40 

20 

SCAN 

15 

20 

SCAN 

4 

20 

SBP 

24 

20 

SBF 

28 

20 

SBF 

33 

20 

PSBF 

12 

20 

PSBF 

38 

20 

PSBF 

17 

20 

Disk 

Request 

Service 

Bulk 

Service 

Core 

Osage 

6=1.00 

FIFO 

0 

19 

FIFO 

0 

19 

FIPO 

14 

19 

g=  * 

MSCAN 

25 

20 

MSCAN 

18 

20 

MSCAN 

36 

20 

i=.3  5 

SCAN 

40 

20 

SCAN 

19 

20 

SCAN 

5 

20 

SBF 

20 

19 

SBF 

26 

19 

SBF 

28 

19 

PSBF 

13 

20 

PSBF 

35 

20 

PSBF 

15 

20 

Disk 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=1.00 

FIPO 

0 

10 

FIFO 

0 

10 

FIFO 

0 

10 

g=  * 

MSCAN 

10 

10 

MSCAN 

7 

10 

MSCAN 

14 

10 

i=-45 

SCAN 

32 

16 

SCAN 

22 

16 

SCAN 

20 

16 

SBP 

10 

10 

SBF 

13 

10 

SBF 

14 

10 

PSBP 

4 

10 

PSBF 

14 

10 

PSBF 

8 

10 

Disk 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=1.00 

PIFO 

0 

2 

FIFO 

0 

2 

FIFO 

0 

2 

g=  * 

MSCAN 

0 

2 

MSCAN 

0 

2 

MSCAN 

0 

2 

i=-55 

SCAN 

16 

8 

SCAN 

16 

8 

SCAN 

16 

8 

SBF 

0 

2 

SBF 

0 

2 

SBF 

0 

2 

PSBF 

0 

2 

PSBP 

0 

2 

PSBF 

0 

2 

Disk  Performance  Comparisons  Summing  over  g 
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Disk 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=2.00 

FIPO 

0 

20 

FIPO 

0 

20 

FIFO 

8 

20 

g=  * 

fISCAN 

23 

20 

MSCAN 

22 

20 

MSCAN 

28 

20 

i=.05 

SCAM 

32 

20 

SCAN 

17 

20 

SCAN 

13 

20 

SBP 

23 

20 

SBP 

26 

20 

SBF 

28 

20 

PSBP 

22 

20 

PSBP 

35 

20 

PSBF 

23 

20 

Disk 

Request 

Service 

Bulk 

Service 

Core 

Usaqe 

6=2-00 

PIPO 

0 

20 

FIFO 

1 

20 

FIFO 

17 

20 

g=  * 

MSCAN 

21 

20 

MSCAN 

21 

20 

MSCAN 

33 

20 

i=.  15 

SCAN 

40 

20 

SCAN 

13 

20 

SCAN 

2 

20 

SBP 

20 

20 

SBF 

26 

20 

SBF 

33 

20 

PSBF 

19 

20 

PSBF 

39 

20 

PSBF 

15 

20 

Disk 

t 

Request 

Service 

Bulk 

Service 

Core 

Osage 

6=2-00 

PIPO 

0 

19 

FIFO 

1 

19 

FIFO 

19 

19 

g=  * 

MSCAN 

19 

19 

MSCAN 

11 

19 

MSCAN 

25 

19 

i=-25 

SCAN 

40 

20 

SCAN 

19 

20 

SCAN 

4 

20 

SBP 

23 

20 

SBF 

31 

20 

SBP 

33 

20 

PSBP 

16 

20 

PSBF 

36 

20 

PSBF 

17 

20 

Disk 

Request 

Service 

Bulk 

Service 

Core 

Osage 

6=2.00 

PIPO 

0 

2 

FIFO 

0 

2 

FIFO 

0 

2 

g=  * 

MSCAN 

0 

2 

MSCAN 

0 

2 

MSCAN 

0 

2 

i=-35 

SCAN 

16 

8 

SCAN 

16 

8 

SCAN 

16 

8 

SBP 

0 

2 

SBF 

0 

2 

SBF 

0 

2 

PSBP 

0 

2 

PSBF 

0 

2 

PSBF 

0 

2 

Disk 

Request 

Service 

Bulk 

Service 

Core 

Usaqe 

6=2.00 

PIPO 

0 

0 

FIFO 

0 

0 

FIFO 

0 

0 

g=  * 

MSCAN 

0 

0 

MSCAN 

0 

0 

MSCAN 

0 

0 

i=.45 

SCAN 

0 

0 

SCAN 

0 

0 

SCAN 

0 

0 

SBP 

0 

0 

SBF 

0 

0 

SBF 

0 

0 

PSBP 

0 

0 

PSBF 

0 

0 

PSBF 

0 

0 

Disk 

Request 

Service 

Bulk 

Service 

Core 

Usaqe 

6=2.00 

PIPO 

0 

0 

FIFO 

0 

0 

FIPO 

0 

0 

g=  * 

MSCAN 

0 

0 

MSCAN 

0 

0 

MSCAN 

0 

0 

i=.55 

SCAN 

0 

0 

SCAM 

0 

0 

SCAN 

0 

0 

SBP 

0 

0 

SBF 

0 

0 

SBP 

0 

0 

PSBF 

0 

0 

PSBP 

0 

0 

PSBF 

0 

0 

Disk  Performance  Comparisons  Summinq  over  q 
Table  C.2b  (cont.). 


179 


Drum 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=  * 

PIPO 

0 

16 

FIFO 

0 

16 

FIFO 

16 

16 

g=  2 

HSCAN 

20 

16 

HSCAN 

20 

16 

HSCAN 

17 

16 

i=-05 

SCAN 

20 

16 

SCAN 

20 

16 

SCAN 

14 

16 

SBP 

20 

16 

SBF 

20 

16 

SBF 

17 

16 

PSBP 

20 

16 

PSBP 

20 

16 

PSBF 

16 

16 

Drum 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=  * 

PIPO 

0 

16 

FIFO 

1 

16 

FIFO 

16 

16 

g=  2 

HSCAN 

20 

16 

HSCAN 

16 

16 

HSCAN 

21 

16 

i=.  15 

SCAN 

20 

16 

SCAN 

19 

16 

SCAN 

7 

16 

SBP 

20 

16 

SBF 

18 

16 

SBF 

21 

16 

PSBP 

20 

16 

PSBF 

26 

16 

PSBF 

15 

16 

Drum 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=  * 

PIPO 

0 

16 

PIFO 

2 

16 

FIFO 

19 

16 

g=  2 

HSCAN 

17 

16 

HSCAN 

14 

16 

HSCAN 

24 

16 

i=-25 

SCAN 

28 

16 

SCAN 

17 

16 

SCAN 

4 

16 

SBP 

18 

16 

SBF 

21 

16 

SBF 

24 

16 

PSBP 

17 

16 

PSBF 

26 

16 

PSBF 

9 

16 

Drum 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=  * 

PIPO 

0 

16 

FIFO 

1 

16 

FIFO 

21 

16 

g=  2 

HSCAN 

16 

16 

HSCAN 

11 

16 

HSCAN 

24 

16 

i=.35 

SCAN 

32 

16 

SCAN 

20 

16 

SCAN 

3 

16 

SBP 

16 

16 

SBF 

20 

16 

SBF 

24 

16 

PSBP 

16 

16 

PSBP 

28 

16 

PSBF 

8 

16 

Drum 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=  * 

FIFO 

0 

13 

FIFO 

0 

13 

FIFO 

14 

13 

g=  2 

HSCAN 

12 

13 

HSCAN 

9 

13 

HSCAN 

19 

13 

i=.45 

SCAN 

32 

16 

SCAN 

25 

16 

SCAN 

10 

16 

SBF 

12 

13 

SBF 

13 

13 

SBF 

19 

13 

PSBP 

12 

13 

PSBF 

21 

13 

PSBF 

6 

13 

Drum 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=  * 

FIFO 

0 

12 

FIFO 

0 

12 

FIFO 

17 

12 

q=  2 

HSCAN 

12 

12 

HSCAN 

8 

12 

HSCAN 

18 

12 

i=.55 

SCAN 

24 

12 

SCAN 

19 

12 

SCAN 

1 

12 

SBF 

12 

12 

SBF 

14 

12 

SBF 

18 

12 

PSBP 

12 

12 

PSBP 

19 

12 

PSBF 

6 

12 

Drum  Performance  Comparisons  Summing  over 
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Drum 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=  * 

PIPO 

0 

16 

PIPO 

0 

16 

FIFO 

6 

16 

g=  5 

HSCAN 

20 

16 

HSCAN 

20 

16 

HSCAN 

19 

16 

i=.05 

SCAN 

20 

16 

SCAN 

20 

16 

SCAN 

18 

16 

SBP 

20 

16 

SBP 

20 

16 

SBP 

19 

16 

PSBP 

20 

16 

PSBP 

20 

16 

PSBP 

18 

16 

Drum 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=  * 

PIPO 

0 

16 

PIPO 

1 

16 

FIFO 

8 

16 

g=  5 

HSCAN 

16 

16 

HSCAN 

19 

16 

HSCAN 

22 

16 

i=- 15 

SCAN 

32 

16 

SCAN 

16 

16 

SCAN 

10 

16 

SBP 

16 

16 

SBP 

20 

16 

SBP 

22 

16 

PSBP 

16 

16 

PSBP 

24 

16 

PSBF 

18 

16 

Drum 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6*  * 

PIPO 

0 

16 

PIPO 

1 

16 

PIPO 

10 

16 

g=  5 

HSCAN 

16 

16 

HSCAN 

17 

16 

HSCAN 

25 

16 

i=.25 

SCAN 

32 

16 

SCAN 

14 

16 

SCAN 

4 

16 

SBP 

16 

16 

SBP 

21 

16 

SBF 

25 

16 

PSBP 

16 

16 

PSBP 

27 

16 

PSBF 

16 

16 

Drum 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=  * 

PIPO 

0 

16 

FIFO 

1 

16 

PIPO 

13 

16 

g=  5 

HSCAN 

16 

16 

HSCAN 

16 

16 

HSCAN 

25 

16 

i=.35 

SCAN 

32 

16 

SCAN 

14 

16 

SCAN 

2 

16 

SBP 

16 

16 

SBF 

20 

16 

SBF 

25 

16 

PSBP 

16 

16 

PSBP 

29 

16 

PSBP 

15 

16 

Drum 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6*  * 

PIPO 

0 

13 

FIFO 

0 

13 

PIPO 

7 

13 

g=  5 

HSCAN 

12 

13 

HSCAN 

12 

13 

HSCAN 

20 

13 

i=.45 

SCAN 

32 

16 

SCAN 

20 

16 

SCAN 

9 

16 

SBP 

12 

13 

SBF 

15 

13 

SBP 

20 

13 

PSBP 

12 

13 

PSBF 

21 

13 

PSBF 

12 

13 

Drum 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=  * 

PIPO 

0 

12 

FIFO 

0 

12 

PIPO 

10 

12 

g=  5 

HSCAN 

12 

12 

HSCAN 

11 

12 

HSCAN 

19 

12 

i=.55 

SCAN 

24 

12 

SCAN 

12 

12 

SCAN 

1 

12 

SBP 

12 

12 

SBF 

15 

12 

SBP 

19 

12 

PSBP 

12 

12 

PSBP 

22 

12 

PSBF 

11 

12 

Drum  Performance  Comparisons  Summing  over  6 
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Drum 

Request 

Service 

Bulk 

Service 

Core 

Osage 

6=  * 

PIPO 

0 

16 

PIFO 

0 

16 

FIFO 

5 

16 

g=10 

MSCAN 

20 

16 

MSCAN 

20 

16 

MSCAN 

20 

16 

i=.05 

SCAN 

20 

16 

SCAN 

18 

16 

SCAN 

15 

16 

SBP 

20 

16 

SBF 

21 

16 

SBF 

20 

16 

PSBP 

20 

16 

PSBF 

21 

16 

PSBF 

20 

16 

Drum 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=  * 

PIPO 

0 

16 

FIFO 

1 

16 

PIPO 

6 

16 

g=10 

MSCAN 

16 

16 

MSCAN 

19 

16 

MSCAN 

23 

16 

i«-15 

SCAN 

32 

16 

SCAN 

13 

16 

SCAN 

9 

16 

SBF 

16 

16 

SBF 

20 

16 

SBF 

23 

16 

PSBP 

16 

16 

PSBP 

27 

16 

PSBF 

19 

16 

Drum 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=  * 

PIPO 

0 

16 

FIFO 

1 

16 

FIFO 

7 

16 

g=10 

MSCAN 

16 

16 

MSCAN 

18 

16 

MSCAN 

26 

16 

i=.25 

SCAN 

32 

16 

SCAN 

12 

16 

SCAN 

4 

16 

SBF 

16 

16 

SBF 

20 

16 

SBF 

26 

16 

PSBP 

16 

16 

PSBP 

29 

16 

PSBF 

17 

16 

Drum 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=  * 

PIPO 

0 

16 

FIFO 

1 

16 

FIFO 

8 

16 

g=10 

MSCAN 

16 

16 

MSCAN 

17 

16 

MSCAN 

26 

16 

i=.35 

SCAN 

32 

16 

SCAN 

12 

16 

SCAN 

3 

16 

SBF 

16 

16 

SBF 

22 

16 

SBF 

26 

16 

PSBP 

16 

16 

PSBP 

28 

16 

PSBF 

17 

16 

Drum 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=  * 

PIPO 

0 

16 

FIFO 

0 

16 

FIFO 

5 

16 

g=10 

MSCAN 

16 

16 

MSCAN 

15 

16 

MSCAN 

27 

16 

i=-45 

SCAN 

32 

16 

SCAN 

12 

16 

SCAN 

u 

16 

SBF 

16 

16 

SBF 

23 

16 

SBF 

27 

16 

PSBP 

16 

16 

PSBF 

30 

16 

PSBF 

17 

16 

Drum 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=  * 

PIPO 

0 

12 

FIFO 

0 

12 

FIFO 

7 

12 

g=10 

MSCAN 

12 

12 

MSCAN 

11 

12 

MSCAN 

20 

12 

i=.55 

SCAN 

24 

12 

SCAN 

10 

12 

SCAN 

1 

12 

SBP 

12 

12 

SBF 

15 

12 

SBF 

20 

12 

PSBP 

12 

12 

PSBF 

24 

12 

PSBF 

12 

12 

Drum  Performance  Comparisons  Summing  over 
Table  C.3a  (cont.). 


182 


Drum 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=  * 

PIPO 

0 

16 

PIPO 

0 

16 

PIPO 

5 

16 

g=20 

MSCAN 

20 

16 

MSCAN 

20 

16 

MSCAN 

19 

16 

i=.05 

SCAN 

20 

16 

SCAM 

18 

16 

SCAN 

18 

16 

SBP 

20 

16 

SBP 

21 

16 

SBP 

19 

16 

PSBP 

20 

16 

PSBP 

21 

16 

PSBP 

19 

16 

Drum 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=  * 

PIPO 

0 

16 

PIPO 

1 

16 

PIPO 

6 

16 

g=20 

MSCAN 

18 

16 

MSCAN 

20 

16 

MSCAN 

21 

16 

i=.  15 

SCAN 

26 

16 

SCAN 

12 

16 

SCAN 

11 

16 

SBP 

18 

16 

SBP 

20 

16 

SBP 

21 

16 

PSBP 

18 

16 

PSBP 

27 

16 

PSBP 

21 

16 

Drum 

Request 

Service 

Bulk 

Service 

Core 

Usage 

5=  * 

PIPO 

0 

16 

PIPO 

1 

16 

PIPO 

8 

16 

g=20 

NSCAN 

16 

16 

MSCAN 

19 

16 

MSCAN 

22 

16 

i=,25 

SCAN 

32 

16 

SCAN 

11 

16 

SCAN 

8 

16 

SBP 

16 

16 

SBP 

20 

16 

SBP 

22 

16 

PSBP 

16 

16 

PSBP 

29 

16 

PSBP 

20 

16 

Drum 

Bequest 

Service 

Bulk 

Service 

Core 

Usage 

6=  * 

PIPO 

0 

16 

PIPO 

2 

16 

PIPO 

10 

16 

g=20 

MSCAN 

16 

16 

MSCAN 

17 

16 

MSCAN 

23 

16 

i=.35 

SCAN 

32 

16 

SCAN 

10 

16 

SCAN 

6 

16 

SBP 

16 

16 

SBP 

22 

16 

SBP 

23 

U 

PSBP 

16 

16 

PSBP 

29 

16 

PSBP 

18 

16 

Drum 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=  * 

PIPO 

0 

16 

PIPO 

0 

16 

PIPO 

a 

16 

g=20 

MSCAN 

16 

16 

MSCAN 

18 

16 

MSCAN 

26 

16 

i=.t»5 

SCAN 

32 

16 

SCAN 

10 

16 

SCAN 

6 

16 

SBP 

16 

16 

SBP 

21 

16 

SBP 

26 

16 

PSBP 

16 

16 

PSBP 

31 

16 

PSBP 

18 

16 

Drum 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=  * 

PIPO 

0 

12 

PIFO 

0 

12 

PIPO 

5 

12 

g=20 

MSCAN 

12 

12 

MSCAN 

13 

12 

MSCAN 

18 

12 

i=,55 

SCAN 

24 

12 

SCAN 

8 

12 

SCAN 

3 

12 

SBP 

12 

12 

SBP 

15 

12 

SBP 

19 

12 

PSBP 

12 

12 

PSBP 

24 

12 

PSBP 

15 

12 

Drum  Performance  Comparisons  Summing  over 
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Drum 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=  * 

FIFO 

0 

16 

FIFO 

0 

16 

FIFO 

1 

16 

g=50 

MSCAN 

20 

16 

MSCAN 

21 

16 

MSCAN 

21 

16 

i=.05 

SCAN 

20 

16 

SCAN 

14 

16 

SCAN 

16 

16 

SBF 

20 

16 

SBF 

21 

16 

SBF 

21 

16 

PSBF 

20 

16 

PSBF 

24 

16 

PSBF 

21 

16 

Drum 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=  * 

FIFO 

0 

16 

FIFO 

1 

16 

FIFO 

4 

16 

g=50 

MSCAN 

16 

16 

MSCAN 

20 

16 

MSCAN 

23 

16 

i=.  15 

SCAN 

32 

16 

SCAN 

9 

16 

SCAN 

8 

16 

SBF 

16 

16 

SBF 

20 

16 

SBF 

23 

16 

PSBF 

16 

16 

PSBF 

30 

16 

PSBF 

22 

16 

Drum 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=  * 

FIFO 

0 

16 

FIFO 

2 

16 

FIFO 

8 

16 

g=50 

MSCAN 

16 

16 

MSCAN 

17 

16 

MSCAN 

24 

16 

i=.25 

SCAN 

32 

16 

SCAN 

8 

16 

SCAN 

5 

16 

SBF 

16 

16 

SBF 

22 

16 

SBF 

24 

16 

PSBF 

16 

16 

PSBF 

31 

16 

PSBF 

19 

16 

Drum 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=  * 

FIPO 

0 

14 

FIFO 

0 

14 

FIFO 

3 

14 

g=50 

MSCAN 

12 

14 

MSCAN 

15 

14 

MSCAN 

19 

14 

i=.35 

SCAN 

32 

16 

SCAN 

12 

16 

SCAN 

9 

16 

SBF 

18 

16 

SBF 

23 

16 

SBF 

21 

16 

PSBF 

12 

14 

PSBF 

24 

14 

PSBF 

16 

14 

Drum 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=  * 

FIFO 

0 

12 

FIFO 

0 

12 

FIFO 

4 

12 

g=50 

MSCAN 

12 

12 

MSCAN 

15 

12 

MSCAN 

19 

12 

i=.45 

SCAN 

24 

12 

SCAN 

6 

12 

SCAN 

3 

12 

SBF 

12 

12 

SBF 

15 

12 

SBF 

19 

12 

PSBF 

12 

12 

PSBF 

24 

12 

PSBF 

15 

12 

Drum 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6*  * 

FIFO 

0 

12 

FIFO 

0 

12 

FIFO 

1 

12 

g=50 

MSCAN 

13 

12 

MSCAN 

14 

12 

MSCAN 

20 

12 

i=-55 

SCAN 

24 

12 

SCAN 

6 

12 

SCAN 

5 

12 

SBF 

13 

12 

SBF 

16 

12 

SBF 

20 

12 

PSBF 

10 

12 

PSBF 

24 

12 

PSBF 

14 

12 

Drum  Performance  Comparisons  Summing  over 
Table  C.3a  (cont. )• 
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Disk 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6*  * 

.   FIPO 

0 

16 

FIPO 

0 

16 

FIPO 

10 

16 

g-  2 

MSCAN 

20 

16 

MSCAN 

19 

16 

MSCAN 

19 

16 

i=.05 

SCAN 

20 

16 

SCAN 

19 

16 

SCAN 

15 

16 

SBP 

20 

16 

SBF 

20 

16 

SBF 

20 

16 

PSBP 

20 

16 

PSBF 

22 

16 

PSBP 

16 

16 

Disk 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=  * 

FIPO 

0 

16 

PIFO 

1 

16 

FIFO 

15 

16 

g=  2 

MSCAN 

18 

16 

MSCAN 

17 

16 

MSCAI 

26 

16 

i=.15 

SCAN 

32 

16 

SCAN 

19 

16 

SCAN 

6 

16 

SBP 

19 

16 

SBF 

20 

16 

SBF 

26 

16 

PSBP 

11 

16 

PSBF 

23 

16 

PSBP 

7 

16 

Disk 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=  * 

FIFO 

0 

16 

FIFO 

1 

16 

FIFO 

18 

16 

g=  2 

MSCAN 

19 

16 

MSCAN 

12 

16 

MSCAN 

27 

16 

i=.25 

SCAN 

32 

16 

SCAN 

24 

16 

SCAN 

3 

16 

SBF 

19 

16 

SBF 

22 

16 

SBF 

26 

16 

PSBP 

10 

16 

PSBF 

21 

16 

PSBF 

6 

16 

Disk 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=  * 

FIPO 

0 

12 

FIFO 

0 

12 

FIPO 

12 

12 

g=  2 

MSCAN 

15 

12 

MSCAN 

9 

12 

MSCAN 

21 

12 

i=.  35 

SCAN 

24 

12 

SCAN 

20 

12 

SCAN 

3 

12 

SBF 

15 

12 

SBF 

17 

12 

SBP 

21 

12 

PSBP 

6 

12 

PSBF 

14 

12 

PSBP 

3 

12 

Disk 

Request 

Service 

Bulk 

Service 

Core 

Osage 

6=  * 

PIFO 

0 

9 

FIFO 

0 

9 

FIFO 

4 

9 

g=  2 

MSCAN 

10 

9 

MSCAN 

6 

9 

MSCAN 

14 

9 

i=-45 

SCAN 

24 

12 

SCAN 

24 

12 

SCAN 

12 

12 

SBF 

10 

9 

SBF 

12 

9 

SBF 

14 

9 

PSBF 

4 

9 

PSBP 

6 

9 

PSBF 

4 

9 

Disk 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=  * 

FIFO 

0 

4 

FIFO 

0 

g 

FIFO 

0 

4 

g=  2 

MSCAN 

5 

5 

MSCAN 

4 

5 

MSCAN 

7 

5 

i=-55 

SCAN 

16 

8 

SCAN 

16 

8 

SCAN 

12 

8 

SBF 

5 

5 

SBF 

6 

5 

SBF 

7 

5 

PSBF 

0 

4 

PSBF 

0 

4 

PSBF 

0 

4 

Disk    Performance  Comparisons   Summing   over    <5 
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Disk 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=  * 

FIPO 

0 

16 

FIFO 

0 

16 

FIFO 

2 

16 

g=  5 

MSCAN 

18 

16 

MSCAN 

20 

16 

MSCAN 

21 

16 

i=-05 

SCAN 

26 

16 

SCAN 

19 

16 

SCAN 

17 

16 

SBP 

18 

16 

SBF 

20 

16 

SBF 

21 

16 

PSBP 

18 

16 

PSBF 

21 

16 

PSBF 

19 

16 

Disk 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=  * 

PIPO 

0 

16 

FIFO 

0 

16 

FIFO 

6 

16 

g=  5 

MSCAN 

19 

16 

MSCAN 

17 

16 

MSCAN 

26 

16 

i=-15 

SCAN 

32 

16 

SCAN 

15 

16 

SCAN 

6 

16 

SBP 

19 

16 

SBF 

21 

16 

SBF 

26 

16 

PSBP 

10 

16 

PSBF 

27 

16 

PSBF 

16 

16 

Disk 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=  * 

PIPO 

0 

16 

FIFO 

0 

16 

FIFO 

10 

16 

g=  5 

MSCAN 

20 

16 

MSCAN 

14 

16 

MSCAN 

28 

16 

i=.25 

SCAN 

32 

16 

SCAN 

13 

16 

SCAN 

3 

16 

SBP 

20 

16 

SBF 

24 

16 

SBF 

28 

16 

PSBP 

8 

16 

PSBP 

29 

16 

PSBF 

11 

16 

Disk 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=  * 

PIPO 

0 

12 

FIFO 

0 

12 

FIFO 

10 

12 

g=  5 

MSCAN 

15 

12 

MSCAN 

9 

12 

MSCAN 

21 

12 

i=.35 

SCAN 

24 

12 

SCAN 

10 

12 

SCAN 

0 

12 

SBP 

15 

12 

SBF 

20 

12 

SBF 

21 

12 

PSBP 

6 

12 

PSBF 

21 

12 

PSBF 

8 

12 

Disk 

Request 

Serv 

ice 

Bulk 

Service 

Core 

Usage 

6=  * 

PIPO 

0 

9 

FIFO 

0 

9 

FIFO 

3 

9 

g=  5 

MSCAN 

10 

9 

MSCAN 

6 

9 

MSCAN 

14 

9 

i=-45 

SCAN 

24 

12 

SCAN 

16 

12 

SCAN 

10 

12 

SBP 

10 

9 

SBF 

12 

9 

SBF 

14 

9 

PSBP 

4 

9 

PSBF 

14 

9 

PSBF 

7 

9 

Disk 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=  * 

FIPO 

0 

7 

FIFO 

0 

7 

FIFO 

0 

7 

g=  5 

MSCAN 

10 

8 

MSCAN 

6 

8 

MSCAN 

14 

8 

i=.55 

SCAN 

16 

8 

SCAN 

13 

8 

SCAN 

6 

8 

SBF 

10 

8 

SBF 

13 

8 

SBF 

14 

8 

PSBP 

2 

7 

PSBF 

6 

7 

PSBF 

4 

7 

Disk  Performance  Comparisons  Summing  over  6 
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Disk 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=  * 

PIFO 

0 

16 

PIFO 

0 

16 

FIFO 

1 

16 

g=10 

NSCAN 

20 

16 

MSCAN 

19 

16 

NSCAN 

21 

16 

i=,05 

SCAN 

22 

16 

SCAN 

17 

16 

SCAN 

17 

16 

SBP 

20 

16 

SBF 

21 

16 

SBF 

21 

16 

PSBP 

18 

16 

PSBF 

23 

16 

PSBF 

20 

16 

Disk 

Request 

Serv 

ice 

Bulk 

Service 

Core 

Usage 

6=  * 

PIPO 

0 

16 

FIFO 

0 

16 

FIFO 

5 

16 

g=10 

NSCAN 

18 

16 

NSCAN 

18 

16 

NSCAN 

26 

16 

i=.  15 

SCAN 

32 

16 

SCAN 

11 

16 

SCAN 

5 

16 

SBP 

17 

16 

SBF 

20 

16 

SBF 

26 

16 

PSBP 

13 

16 

PSBF 

31 

16 

PSBF 

18 

16 

Disk 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=  * 

PIPO 

0 

16 

PIFO 

0 

16 

PIPO 

9 

16 

g=10 

NSCAN 

20 

16 

NSCAN 

14 

16 

NSCAN 

28 

16 

i=.25 

SCAN 

32 

16 

SCAN 

12 

16 

SCAN 

2 

16 

SBP 

20 

16 

SBF 

23 

16 

SBF 

28 

16 

PSBP 

8 

1*6 

PSBP 

31 

16 

PSBF 

13 

16 

Disk 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=  * 

PIPO 

0 

13 

PIFO 

0 

13 

FIFO 

7 

13 

g=10 

MSCAN 

15 

13 

NSCAN 

10 

13 

NSCAN 

21 

13 

i=-35 

SCAN 

32 

16 

SCAN 

17 

16 

SCAN 

9 

16 

SBP 

15 

13 

SBF 

18 

13 

SBF 

21 

13 

PSBF 

6 

13 

PSBP 

23 

13 

PSBF 

10 

13 

Disk 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=  * 

PIPO 

0 

12 

FIFO 

0 

12 

FIFO 

3 

12 

g=10 

MSCAN 

15 

12 

NSCAN 

9 

12 

NSCAN 

21 

12 

i=.45 

SCAN 

24 

12 

SCAN 

9 

12 

SCAN 

4 

12 

SBP 

15 

12 

SBF 

20 

12 

SBF 

21 

12 

PSBP 

6 

12 

PSBF 

22 

12 

PSBF 

11 

12 

Disk 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=  * 

PIPO 

0 

9 

FIFO 

0 

9 

FIFO 

0 

9 

g=10 

NSCAN 

10 

9 

NSCAN 

6 

9 

NSCAN 

14 

9 

i=.55 

SCAN 

24 

12 

SCAN 

14 

12 

SCAN 

12 

12 

SBP 

10 

9 

SBF 

14 

9 

SBF 

14 

9 

PSBP 

4 

9 

PSBF 

14 

9 

PSBF 

8 

9 

Disk  Performance  Comparisons  Summing  over  6 
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Disk 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=  * 

FIFO 

0 

16 

FIFO 

0 

16 

FIFO 

1 

16 

g=20 

MSCAN 

20 

16 

MSCAN 

19 

16 

HSCAN 

20 

16 

i=-05 

SCAN 

20 

16 

SCAN 

18 

16 

SCAN 

19 

16 

SBF 

20 

16 

SBF 

20 

16 

SBF 

20 

16 

PSBF 

20 

16 

PSBF 

23 

16 

PSBF 

20 

16 

Disk 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=  * 

FIFO 

0 

16 

FIFO 

0 

16 

FIFO 

3 

16 

g=20 

MSCAN 

16 

16 

MSCAN 

17 

16 

HSCAN 

23 

16 

i=.  15 

SCAN 

32 

16 

SCAN 

11 

16 

SCAN 

11 

16 

SBF 

16 

16 

SBF 

21 

16 

SBF 

23 

16 

PSBF 

16 

16 

PSBF 

31 

16 

PSBF 

20 

16 

Disk 

Request 

Service 

Bulk 

Service 

Core 

Usage 

5=  * 

FIFO 

0 

16 

FIFO 

0 

16 

FIFO 

7 

16 

g=20 

HSCAN 

t7 

16 

HSCAN 

17 

16 

HSCAN 

23 

16 

i=,25 

Scan 

32 

16 

SCAN 

11 

16 

SCAN 

5 

16 

SBF 

16 

16 

SBF 

20 

16 

SBF 

23 

16 

PSBF 

15 

16 

PSBF 

32 

16 

PSBF 

22 

16 

Disk 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=  * 

FIFO 

0 

13 

FIFO 

0 

13 

FIFO 

5 

13 

g=20 

MSCAN 

14 

13 

MSCAN 

12 

13 

HSCAN 

20 

13 

i=-35 

SCAN 

32 

16 

SCAN 

17 

16 

SCAN 

10 

16 

SBF 

14 

13 

SBF 

16 

13 

SBF 

20 

13 

PSBF 

8 

13 

PSBF 

23 

13 

PSBF 

13 

13 

Disk 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=  * 

FIFO 

0 

12 

FIFO 

0 

12 

FIFO 

1 

12 

g=20 

MSCAN 

15 

12 

MSCAN 

12 

12 

HSCAN 

21 

12 

i=.45 

SCAN 

24 

12 

SCAN 

9 

12 

SCAN 

5 

12 

SBF 

15 

12 

SBF 

17 

12 

SBF 

21 

12 

PSBF 

6 

12 

PSBF 

22 

12 

PSBF 

12 

12 

Disk 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=  * 

PIFO 

0 

9 

FIFO 

0 

9 

FIFO 

0 

9 

g=20 

MSCAN 

10 

9 

MSCAN 

8 

9 

HSCAN 

14 

9 

i=.55 

SCAN 

24 

12 

SCAN 

14 

12 

SCAN 

12 

12 

SBF 

10 

9 

SBF 

12 

9 

SBF 

14 

9 

PSBF 

4 

9 

PSBF 

14 

9 

PSBF 

8 

9 

Disk  Performance  Comparisons  Summing  over  <$ 
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Disk 

Request 

Service 

Bulk 

Service 

Core 

Osage 

6=  * 

PIFO 

0 

16 

PIPO 

0 

16 

FIFO 

0 

16 

g=50 

MSCAN 

17 

16 

MSCAN 

19 

16 

MSCAN 

21 

16 

i=.05 

SCAN 

29 

16 

SCAN 

14 

16 

SCAN 

18 

16 

SBP 

17 

16 

SBF 

20 

16 

SBF 

21 

16 

PSBP 

17 

16 

PSBP 

27 

16 

PSBF 

20 

16 

Disk 

Bequest 

Service 

Bulk 

Service 

Core 

Usage 

6=  * 

PIFO 

0 

16 

PIFO 

0 

16 

FIFO 

4 

16 

g=50 

MSCAN 

16 

16 

MSCAN 

20 

16 

MSCAN 

26 

16 

i=.15 

SCAN 

32 

16 

SCAN 

8 

16 

SCAM 

6 

16 

SBP 

16 

16 

SBP 

20 

16 

SBF 

26 

16 

PSBP 

16 

16 

PSBP 

32 

16 

PSBF 

18 

16 

Disk 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=  * 

PIPO 

0 

15 

FIFO 

0 

15 

FIFO 

1 

15 

g=50 

MSCAN 

15 

15 

MSCAN 

15 

15 

MSCAN 

19 

15 

i=.25 

SCAN 

32 

16 

SCAN 

10 

16 

SCAN 

9 

16 

SBP 

20 

16 

SBF 

21 

16 

SBF 

27 

16 

PSBP 

11 

16 

PSBP 

32 

16 

PSBF 

22 

16 

Disk 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6  =  * 

PIPO 

0 

11 

FIFO 

0 

1  1 

FIFO 

0 

11 

g=50 

MSCAN 

15 

12 

MSCAN 

14 

12 

MSCAN 

22 

12 

i=.  35 

SCAN 

24 

12 

SCAN 

10 

12 

SCAN 

8 

12 

SBP 

10 

11 

SBF 

10 

11 

SBP 

14 

11 

PSBP 

9 

12 

PSBF 

24 

12 

PSBP 

14 

12 

Disk 

Request 

Service 

Bulk 

Service 

/ 

Core 

Usage 

6=  * 

PIFO 

0 

8 

FIFO 

0 

8 

FIFO 

0 

8 

g=50 

MSCAN 

10 

8 

MSCAN 

7 

8 

MSCAN 

13 

8 

i=-  U5 

SCAN 

16 

8 

SCAN 

5 

6 

SCAN 

4 

8 

SBP 

10 

8 

SBF 

12 

8 

SBF 

14 

8 

PSBP 

U 

8 

PSBF 

16 

8 

PSBF 

9 

8 

Disk 

Request 

Service 

Bulk 

Service 

Core 

Usage 

6=  * 

PIFO 

0 

7 

FIFO 

0 

7 

FIFO 

0 

7 

g=50 

MSCAN 

10 

8 
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10 

8 
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13 

8 
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8 
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7 

8 
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8 
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8 
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13 

8 
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15 

8 
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7 
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8 

7 
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4 

7 
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